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The  intent  of  this  research  has  been  to  identify  system 


input  and  output  changes  that  will  be  needed  to  transport 
FRESH  (an  employment  scheduling  expert  system)  from 
CINCPACFLT  to  CINCLANTFLT.  A  general  discussion  of  expert 
system  theory  is  presented  tying  this  theory  to  FRESH 
wherever  possible.  Specific  uses  of  FRESH  at  CINCPACFLT  are 
discussed  as  well  as  the  present  Pacific  FRESH  input  and 
output  requirements.  CINCLANTFLT 1 s  existing  manual  method 
of  scheduling  is  discussed.  Finally  CINCLANTFLT ' s  proposed 
changes  to  the  Pacific  FRESH  inputs  and  outputs  are 
analyzed.  Conclusions  identify  what  FRESH  inputs  and 
outputs  must  be  changed  prior  to  FRESH  transference  to 
CINCLANTFLT. 
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This  research  will  look  into  what  needs  to  be  changed, 
in  terms  of  the  system  inputs  and  outputs,  in  order  to 
transport  the  expert  system  FRESH  to  the  Commander  in  Chief 
Atlantic  Fleet  (CINCLANTFLT)  Norfolk,  VA. 

I 

i 

A.  FRESH  OVERVIEW 

FRESH  is  an  expert  system  developed  by  Texas  Instruments 
Corp.  and  BTG  Inc.  and  is  presently  being  prototyped  at 
Commander  in  Chief  Pacific  Fleet  (CINCPACFLT) ,  Pearl  Harbor, 
HI.  According  to  the  Pacific  Fleet  Headquarters,  "FRESH  is 
an  extremely  useful  expert  system  prototype  that  is  used: 

f  to  generate  long  range  ship's  employment  schedules — a 
>  macro  ship's  schedule  which  covers  all  major  events  for 
a  ship  over  a  five  year  period^ 

2^  f  to  monitor  changes  that  impact  Fleet  readiness  and 
provide  viable  replacements  for  units  with  major 
casualties^ 

'■>  -  to  evaluate  the  impact  of  rescheduling  ships  &>■  L 

-  -  to  improve  effectiveness  of  valuable  personnel 
resources.  ^ ^ ^  j  4  _ 

The  specific  capabilities  of  FRESH  are  presented  in  more 
detail  in  Chapter  III  of  this  research,  however  at  this 
point,  suffice  it  to  say  that  FRESH  is  proving  to  be  a  very 
valuable  decision  aid. 


B.  EXPERT  SYSTEMS 

Expert  Systems,  like  FRESH,  have  been  flooding  the 
marketplace  over  the  last  ten  years.  They  are  computer 
based  systems  incorporating  human  "expertise"  to  help 
decision  makers  in  complex  decision  environments  and  are 
emerging  as  significant  components  of  operational 
human-machine  systems  [LANE  1986:121-125].  To  date,  expert 
systems  have  been  used  extensively  in  Medical  Diagnosis, 
Mineral  Prospecting,  Chemistry,  Mathematics,  Speech 
Recognition,  High  Value  Target  Analysis,  and  Oil  Drilling 
[TETER  1986:2-26].  Likewise,  the  Department  of  Defense 
(DOD)  is  a  strong  believer  in  expert  systems  and  their 
present/ future  applications  to  Command,  Control, 
Communications,  and  Intelligence  (C3I)  systems.  Many 
military  applications  have  been  implemented  from  an  expert 
system  to  train  jet  fighter  pilots  to  an  expert  system  to 
help  DOD  make  smarter  purchasing  decisions  in  today's  high 
cost  procurement  world. 

One  of  the  major  stumbling  blocks  in  today's  DOD 
computer  systems  is  that  they  involve  software  which  is 
"non-portable,  inflexible  and  largely  unresponsive, 
expensive  to  develop  and  maintain,  with  little  or  no 
interoperability  and  few  standards...."  [LASHER  1982:26] 

In  short,  expert  systems  are  a  part  of  DOD  that  although 
becoming  well  entrenched,  require  further  attention  to 
overcome  the  previously  mentioned  shortfalls. 
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C.  OBJECTIVES/RESEARCH  QUESTIONS 

The  overall  research  question  driving  this  thesis  is 
concerned  with  changes  to  FRESH  to  transport  it  to  the 
Commander  in  Chief  Atlantic  Fleet  (CINCLANTFLT) — 
specifically  system  input  and  output  changes  needed. 

The  answer  to  this  question  is  not  trivial.  The 
Atlantic  and  Pacific  Fleets  are  run  somewhat  differently. 
This  research  is  intended  to  identify  these  differences  in 
so  far  as  required  system  inputs  to  FRESH  and  desired  system 
outputs  from  FRESH  are  concerned.  In  other  words,  what 
changes,  regarding  system  input  and  output  requirements, 
must  be  made  to  FRESH  such  that  it  meets  the  requirements  of 
the  Atlantic  Fleet?  Many  Pacific  Fleet  FRESH  input 
documents  may  be  different  than  their  counterparts  on  the 
Atlantic  side.  Likewise,  the  Atlantic  Fleet  may  see 
different  uses  for  FRESH  and  require  the  output  in  some 
other  form  than  is  presently  provided  by  the  Pacific  FRESH. 

D.  SCOPE 

This  thesis  is  concerned  only  with  the  external  system 
inputs  and  outputs  of  FRESH.  It  is  not  a  research  project 
on  the  inner  decision  making  processes  found  in  FRESH,  nor 
is  it  designed  to  prove  FRESH's  effectiveness. 

E.  ASSUMPTIONS  AND  LIMITATIONS 

One  intent  of  this  research  was  to  assess  the  cost  of 
making  the  required  changes.  However,  while  conducting  this 


!,  ■  ,Ku'  .  <4 k 


research  and  talking  with  Texas  Instrument  personnel  it 
became  readily  apparent  that  these  "change  costs"  could  not 
be  quantified.  The  reason  for  this  is  that  T.I.  can  not 
produce  a  cost  estimate  unless  contracted  to  do  so. 

Another  limitation  was  the  under-funding  of  travel. 
Although  funding  was  available  for  a  single  trip  to 
CINCPACFLT  headquarters,  there  was  insufficient  funding  for 
the  author  to  travel  to  CINCLANTFLT  headquarters  and  Texas 
Instruments  in  Dallas,  Texas.  This  inability  to  travel  to 
CINCLANTFLT  headquarters  forced  the  author  to  base  his 
Atlantic  Fleet  findings  on  written  correspondence  and 
telephone  conversations  with  appropriate  personnel.  This 
should  not  seriously  affect  the  results. 

Interest  in  FRESH  was  assumed  to  be  high  at  CINCLANTFLT 
headquarters.  In  most  cases  this  assumption  held  to  be 
true.  However,  soliciting  and  receiving  information  from 
CINCLANTr,TT  was  difficult  due  in  large  part  to  the 
aforementioned  travel  funding  constraint. 

The  author  feels  that  this  thesis  research  will  prove  to 
be  very  useful.  FRESH  represents  a  valid  requirement  at 
CINCLANTFLT  and  this  cornerstone  research  into  the 
transportability  of  FRESH  will  provide  valuable  background 
for  those  attempting  the  actual  transportation  of  FRESH  in 
the  near  future. 
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F .  METHODOLOGY 

This  research  was  carried  out  through  an  investigative 
approach  that  involved  theoretical  analysis  of  expert 
systems,  a  practical  evaluation  of  FRESH  and  an  overview  of 
the  external  hardcopy  inputs  and  outputs  required  of  both 
Fleets . 


G.  ORGANIZATION  OF  THESIS 

Chapter  II  presents  an  overview  of  Expert  System  Theory 
including  a  review  of  literature  relevant  to  expert  systems 
history,  development  and  terminology. 

Chapter  III  depicts  CINCPACFLT's  external  hardcopy  input 
and  output  requirements  for  FRESH.  Also  this  chapter 
contains  a  comprehensive  overview  of  the  uses  of  FRESH  in 
CINCPACFLT . 

Chapter  IV  presents  an  overview  of  the  present 
CINCLANTFLT  employment  scheduling  system  concentrating  on 
their  required  external,  hardcopy  inputs  and  outputs.  Then 
the  CINCLANTFLT  external  hardcopy  inputs  and  outputs  are 
contrasted  with  their  CINCPACFLT  counterparts  and 
differences  are  highlighted. 

Chapter  V  sets  forth  the  conclusions  and  recommenda¬ 
tions,  regarding  external  hardcopy  inputs  and  outputs,  for 
the  proposed  transfer  of  FRESH  from  CINCPACFLT  to 
CINCLANTFLT . 


II.  EXPERT  SYSTEM  THEORY 


The  design  and  implementation  of  FRESH,  as  in  any 
military  command  and  control  expert  system  is  more 
complicated  than  that  of  an  expert  system  intended  for 
commercial  use.  This  increased  difficulty  arises  because, 
unlike  private  companies,  DOD  has  many  government 
regulations  that  must  be  followed  and  likewise,  the 
continual  turnover  of  military  personnel  throughout  a 
project's  design  and  implementation  can  have  a  negative 
impact . 

FRESH  in  essence  is  a  centrally  controlled,  strategic 
scheduling  system.  It  must  be  able  to  operate  in  both 
peace  and  time-constrained  combat  and  produce  up-to-date, 
realistic,  usable  information  to  the  Fleet  Commander  in 
Chief.  But  even  though  FRESH  is  strategic  in  nature,  lives 
may  be  at  risk  due  to  "wrong  employment  of  forces." 

In  order  to  better  understand  FRESH,  one  must  first 
understand  expert  systems  in  general.  The  goal  of  this 
chapter  is  to  provide  a  basic  introduction  to  expert 
systems.  It  includes  an  overview  of  decision  theory,  expert 
system  history  and  development,  applications  of  expert 
systems  in  the  world  today,  and  how  knowledge  is  acquired 
for  expert  systems. 


A.  THE  BASICS  OF  EXPERT  SYSTEMS 


As  described  by  Stefik  fSTEFIK  1982:1],  expert  systems 
are  problem  solving  programs  designed  to  help  the  user  solve 
substantial,  unstructured  problems  generally  conceded  as 
being  difficult  and  requiring  expertise.  Expert  systems  are 
referred  to  as  "knowledged  based"  because  their  performance 
depends  critically  on  the  use  of  facts  and  heuristics 
representing  the  knowledge  of  human  experts.  Through 
interaction  with  the  user  and  by  exercising  the  internal 
decision  making  logic  provided  by  a  human  expert  in  a 
particular  field  (in  the  case  of  FRESH,  the  CINCPACFLT 
staff) ,  the  expert  system  helps  the  decision  maker  arrive  at 
a  solution  for  the  problem  at  hand.  Hayes-Roth  went  further 
in  his  definition  of  expert  systems  and  described  them  in 
terms  of  seven  features  that  he  considers  fundamental  to  the 
goals  we  should  strive  for  in  an  expert  system.  (HAYES-ROTH 
1983:43-50]  These  features  are: 

1.  Expertise 

The  expert  system  must  act  as  its  expert  human 
counterpart  would — as  much  as  possible  their  'thought 
processes'  should  be  similar.  In  other  words,  FRESH  must 
perform  as  well  as  the  CINCPACFLT  staff,  both  in  timeliness 
and  quality  of  product.  Preliminary  results  have  shown  this 
to  be  true  for  FRESH.  As  witnessed  by  the  author,  in  day  to 
day  realtime  casualty  updating  and  decision  making,  what 


previously  required  several  hours  to  complete  manually,  now 
takes  only  minutes  with  FRESH. 


2 .  Symbol  Manipulation 

According  to  [HAYES-ROTH  1983:45],  expert  systems 
can  not  effectively  use  conventional,  algorithmic  computer 
languages  to  represent  knowledge.  Instead,  they  must  use  a 
symbolic  reasoning  language,  i.e.,  they  utilize  symbols  and 
symbol  structures  to  represent  and  manipulate  knowledge. 

A  brief  Navy  example  is  provided  using  a  common 
symbol  manipulation  language — Predicate  Calculus.  Consider 
a  ship  labeled  (B)  and  a  16'*  gun  labeled  (A)  .  To  denote 
that  the  16"  gun  (A)  is  resting  on  top  of  the  ship  (B) ,  the 
correct  symbolic  syntax  would  be:  (TOP-OF  A  B) ,  where 
TOP-OF  is  the  functional  symbol.  These  functional  symbols 
delineate  relations  between  entities  [STEFIK  1982:4]  and  by 
stringing  these  symbols  together,  knowledge  is  represented. 
Although  this  example  is  simple,  it  gives  a  flavor  of 
symbolic  manipulation  languages.  FRESH  is  written  in  the 
symbolic  manipulation  language  LISP. 

3.  General  Prpfrleff-gplvjnq  Ability  in  ?  popajn 

The  expert  system  should  possess  all  the  available 
knowledge  about  a  particular  domain — in  the  case  of  FRESH, 
its  domain  is  employment  scheduling.  Likewise,  the  expert 
system  should  be  able  to  apply  that  knowledge  not  only  to 
anticipated  problems  (for  FRESH — typical  employment 
scheduling) ,  but  also  unanticipated  problems,  those  one  of  a 


kind,  highly  unstructured  problems.  For  example,  an  urgent 


requirement  for  mine  sweepers  in  the  Persian  Gulf. 


Certain  problem  domains  do  not  qualify  as  potential 


areas  for  expert  system  implementation  because  they  are  not 


complex  enough.  In  other  words,  the  reasoning  involved  in 


these  "simple”  domains  may  not  contain  enough  steps  or 


enough  alternatives  at  any  branch  decision  point  to  warrant 


the  use  of  an  expert  system.  In  order  for  the  requirement 


of  an  expert  system  to  exist,  the  problem  domain  in  question 


must  be  sufficiently  complex  and  difficult. 


An  expert  system  should  be  able  to  take  a  problem 


presented  in  'lay'  terms  and  reformulate  it  into  terms  that 


it  can  use  in  processing  by  expert  rules.  In  other  words, 


the  system  must  be  able  to  take  human  inputs  and  translate 


them  into  appropriate  symbolic  statements  that  can  be  used 


by  the  computer.  FRESH  uses  Natural  Language  Menu  (NL  menu) 


to  facilitate  this  translation.  NL  menu  attempts  to 


translate  English-like  commands  entered  by  the  user  into 


appropriate  expert  system  functions  [TENANT  1984:630]. 


This  means  that  the  expert  system  must  be  able  to 


"explain"  how  it  arrived  at  its  solution  to  a  problem.  No 


senior  Naval  Officer  is  going  to  take  the  recommendation  of 


a  computer  unless  he/ she  can  see  how  that  computer's 


'A*’.';/  -'"S’ 


decision  was  derived — FRESH  must  be  able  to  explain  its 
logic. 

7 .  Task 

An  expert  system  must  be  specific.  It  must  deal 
with  a  specific  problem  domain  rather  than  a  number  of 
different  disjoint,  unrelated  tasks.  FRESH,  an  expert 
system  specifically  designed  for  scheduling  U.S.  Navy  ships 
would  perform  only  that  task,  it  would  not  be  used  for  any 
other  unrelated  task  e.g.,  medical  diagnosis. 

The  above  attributes  of  expert  systems  depict  "the 
optimum  system."  To  date  no  one  system  possesses  all  of  the 
attributes.  In  fact,  reformulation  and  general  problem¬ 
solving  in  a  domain  are  attributes  that  are  still  being 
strived  for  and  are  in  their  infancy  [HAYES-ROTH  1983:47]. 

In  conclusion,  an  expert  system  should  aim  for  all  of  the 
above  attributes  and  have  flexibility  built  into  it  such 
that  it  can  'grow'  as  requirements  change  over  time. 

B.  DECISION  THEORY 

Discussion  of  expert  systems  naturally  includes  the 
topic  of  decision  theory — since  expert  systems  often  are 
used  to  support  a  user  in  making  decisions.  The  context  of 
management  decision  making  is  the  single  most  important 
factor  when  considering  the  design  and  implementation  of  an 
expert  system. 

Simon  proposed  the  idea  that  all  decisions  can  be  boiled 


down  to  three  phases — Intelligence,  Design,  and  Choice 


[SIMON  1971:26].  The  intelligence  phase  is  summarized  as 
problem  finding,  searching  the  environment  for  conditions 
requiring  decisions.  The  design  phase  is  characterized  as 


"inventing,  developing,  and  analyzing  possible  courses  of 
action... to  solve  the  problem"  [DAVIS  1985:310].  Lastly, 
the  choice  phase  involves  selecting  one  of  the  alternatives 
identified  in  the  design  phase.  Although  somewhat 
simplistic,  Simon's  model  of  decision  making  is  often  cited 
in  decision  making  literature.  Mintzberg  touches  on  more 
detail  regarding  the  managerial  decision  maker,  the  most 
likely  candidate  to  become  an  expert  system  user  [MINTZBERG 
1973:45].  Mintzberg  says  that,  "managers  seldom  make 
decisions  as  part  of  a  deliberate,  coherent,  and  continuous 
decision  making  process.  Instead,  the  manager's  workday  is 
characterized  by  brevity,  variety,  and  fragmentation,  with, 
on  average,  less  that  five  minutes  continuously  spent  in  any 
single  activity"  [MINTZBERG  1973:  45].  Anyone  who  has 
witnessed  the  typical  Flag  officer's  workday  will  agree  with 
this. 

Tying  together  the  philosophies  of  Simon  and  Mintzberg, 
an  expert  system  should  support  the  design  and  choice  phases 
of  Simon's  model,  while  simultaneously  reflecting 
Mintzberg 's  theory  on  how  a  management  expert  makes 
decisions,  i.e.,  how  he  makes  use  of  his  time. 


.•V'.-VV 


C.  EXPERT  SYSTEM  HISTORY  AND  DEVELOPMENT 

Roughly  20  years  ago,  Artificial  Intelligence  experts 
set  out  to  make  use  of  the  latest  available  computer 
hardware  and  software  and  devise  computer  systems  that  could 
solve  problems,  answer  questions  and  make  decisions  better 
(or  at  least  much  faster)  than  a  human  could.  These  experts 
wrongly  felt  that  a  powerful  computer,  armed  with  a  set  of 
"laws  of  reasoning"  could  generate  a  "computer  expert"  that 
would  show  superhuman  effort  [HAYES-ROTH  1983:7].  What  they 
overlooked  in  their  initial  research  was  the  impact  of  human 
expert  knowledge.  They  relied  too  heavily  on  the  abilities 
of  the  computer  and  neglected  input  from  the  human  expert. 

In  short,  the  first  attempts  at  expert  systems  involved 
mathematics  and  chemistry  problems  that  fit  a  certain 
structured  decision  making  model  and  followed  specific, 
standard  rules.  When  these  rules  were  applied  by  the 
computer,  math  and  chemistry  problems  could  be  solved.  Two 
examples  of  this  initial  attempt  at  expert  system  technology 
are: 

1.  DENDRAL — Developed  at  Stanford  in  the  mid  1960s  to 
analyze  mass  spectrographic  nuclear  magnetic  resonance 
and  other  chemical  experiment  data  to  infer  the 
plausible  structure  of  an  unknown  chemical  compound. 
[HAYES-ROTH  1983:7] 

2.  MACSYMA — Developed  at  MIT  as  a  follow  on  to  SAINT, 
which  was  developed  in  1961.  It  is  used  to  perform 
simplification  of  differential  and  integral  calculus 
expressions.  [HAYES-ROTH  1983:9] 

Researchers  then  wrongly  concluded  that  this  same  sort 

of  expert  system  could  be  expanded  and  applied  to  a  wider 
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spectrum  of  problems  including  more  difficult,  unstructured 
problems  [BENNETT  1983:210].  As  further  expert  systems 
development  continued  using  this  thinking,  it  soon  became 
apparent  that  researchers  were  more  concerned  with  fitting 
the  problem  to  the  rule-based  model  rather  than  fitting 
solutions  to  the  nonrule-based  unstructured  type  of 
problems.  In  other  words,  they  were  concentrating  on 
problems  that  could  be  solved  using  explicit  models,  those 
that  were  rule-based.  It  soon  became  readily  apparent  that 
the  scope  of  expert  systems  research  was  heading  down  the 
wrong  track.  In  1977,  Edward  Feigenbaum,  in  a  paper 
prepared  for  the  International  Joint  Conference  on 
Artificial  Intelligence,  verbalized  the  conclusion,  "The 
power  of  an  expert  system  derives  from  the  knowledge  it 
possesses,  not  from  the  particular  formalisms  and  inference 
schemes  it  employs."  Thus  the  conclusion  was  reached  that 
knowledge,  i.e.,  human  expert  knowledge,  is  required  in 
order  to  build  a  sufficiently  effective  expert  system. 

Using  the  concept  of  "knowledge  is  power, "  several  expert 
systems  were  developed  which  incorporated  human  expert 
knowledge  and  human  expert  interaction.  [MICHE  1981:8-11] 

A  sample  of  these  include: 

1.  CASNET — Used  for  consultation  in  diagnosis  and 
treatment  of  glaucoma. 

2.  CADUCEUS — Used  for  diagnosis  and  treatment  of  internal 
medical  problems. 

3.  MYCIN — Used  for  diagnosis  and  treatment  of  infectious 
blood  diseases. 
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4.  PROSPECTOR — Used  to  aid  geologists  in  evaluating 
mineral  mining  sites. 

The  above  applications  have  proven  to  be  extremely 
reliable.  In  fact  when  MYCIN's  performance  was  compared 
against  manual,  human  diagnosis  and  treatment,  the  expert 
system  was  shown  to  perform  at  least  as  good  or  superior  to 
most  human  medical  experts  [HAYES-ROTH  1983:10]. 

Based  on  the  above,  it  appears  that  there  have  been  two 
somewhat  distinct  phases  of  expert  system  development: 

-  early  rule  based  systems  that  did  not  use  human  expert 

knowledge. 

-  later  systems  that  incorporated  human  decision  making 

heuristics  within. 

FRESH  is  of  this  latter  category. 

D.  KNOWLEDGE  ACQUISITION 

If  human  expert  knowledge  is  to  be  placed  within  a 
skilled  computer  system,  if  must  first  be  extracted  from  the 
human  expert  and  then  translated  and  organized  in  such  a 
manner  that  it  can  be  effectively  implemented  into  an  expert 
system;  knowledge  acquisition  is  the  term  used  to  describe 
this  action. 

There  have  been  several  methods  of  knowledge  acquisition 
proposed.  Examples  of  four  of  these  techniques  are  [BUI 
1987b] : 

l.  Make  the  Developer  an  Expert 

This  is  a  somewhat  unrealistic,  if  not  extremely 
difficult  method  as  it  involves  requiring  the  developer  to 
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become  an  expert  in  the  field  of  the  system,  i.e.,  the 
developer  of  a  medical  expert  system  would  have  to  learn 
everything  a  medical  doctor  knows  prior  to  system 
development. 

2 .  Use  the  Human  Expert 

This  is  the  opposite  difficult  method  and  involves 
having  the  field  expert  develop  the  expert  system,  i.e.,  the 
doctor  developing  a  medical  expert  system  would  have  to 
become  adept  in  expert  system  development — in  other  words, 
the  doctor  would  have  to  become  a  computer  expert! 

3 .  Knowledge  Engineering 

This  technique  is  the  most  popular.  It  involves  a 
single  knowledge  engineer  (an  expert  system  computer  type) 
becoming  somewhat  familiar  with  the  field  of  study  in 
question  and  through  interaction  with  a  select  few 
application  experts,  translating  the  expert  knowledge  into  a 
computer  expert  system  usable  format.  This  information, 
provided  by  the  knowledge  engineer,  is  then  utilized  by  the 
expert  system  developers  to  produce  the  system.  This  is  in 
fact  the  way  that  FRESH  was  designed  and  implemented.  The 
knowledge  engineer  is  a  Texas  Instrument  employee,  as  are 
the  expert  system  developers,  the  application  experts  are 
CINCPACFLT  Naval  officers. 

4.  Text  Understanding  Mode 

R»  'ntly  there  has  been  research  into  automated 


knowledge  acquisition,  which  basically  involves  computers 


•reading*  books  on  a  particular  application  in  order  to  gain 
the  knowledge  required  to  build  an  appropriate  expert 
system.  Although  this  technology  may  become  useful  in  the 
future,  today,  the  knowledge  engineering  method  appears  to 
be  the  standard  way  of  acquiring  knowledge. 

Because  knowledge  engineering  is  the  most  effective 
and  widely  used  method  of  knowledge  acquisition  set  forth  to 
date,  it  warrants  further  discussion.  There  are  several 
distinct  phases  of  knowledge  acquisition  [HAYES-ROTH  1983: 
140-148] . 

5.  Identification  Phase 

The  following  are  identified:  the  major  human 
experts  to  be  utilized,  problems  to  be  solved,  resources 
available  to  solve  the  problems  and  the  major  goals  to  be 
met.  The  computer  systems  expert  attempts  to  become 
conversant  in  the  language  of  the  application.  This 
involves  repeated  interaction  between  the  knowledge  engineer 
and  the  field  expert. 

6.  c<?n<peptuaUg?tioh  Phase 

In  this  phase,  the  information  collected  in  the 
identification  phase  is  formalized  and  tied  together. 
Conceptualization  should  involve  setting  down  on  paper  in 
the  form  of  diagrams,  narrative  descriptions  etc.,  the  major 
concepts  and  interactions  noted  between  the  above  entities 
discovered  in  the  identification  phase.  Hidden  causal 
relations  and  problem  solving  processes  are  searched  for  and 


identified.  This  again  involves  repeated  interaction 
between  the  knowledge  engineer  and  the  field  expert. 
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7 .  Formalization  Phase 

This  is  a  further  refinement  of  delineating  the  key 
concepts,  subproblems  and  information  flow  characteristics 
found  during  the  conceptualization  phase.  At  this  time,  the 
knowledge  engineer  takes  a  more  active  role  and  sets  forth 
possible  ways  of  setting  up  the  specific  expert  system  to 
solve  the  problems  identified.  Specifically,  models  to 
solve  the  problem  are  discussed,  these  models  can  be  either 
mathematic  or  behavioral.  The  most  likely  expert  system 
building  language  (for  the  particular  application)  will  be 
decided  upon.  Likewise,  methods  and  associated  costs  of 
reliable  data  acquisition  are  highlighted.  The  bottom  line 
is,  what  are  the  problems  that  are  solvable  given  dollar 
constraints? 

8.  implementation  Phase 

This  phase  is  involved  with  integrating  the 
formalized  expert  human  knowledge  collected  in  the  earlier 
phases  into  the  representational  frame  of  the  computer 
system  that  will  form  the  expert  system.  More  clearly 
stated,  this  is  when  the  knowledge  engineer  translates  the 
expert  knowledge  into  a  computer  expert  system  usable 
format.  This  newly  evolved  representation  of  the  human 
expert  knowledge  is  then  used  to  develop  a  prototype  expert 
system. 
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Testing  Phase 


Finally,  the  prototype  is  tested.  Tests  range  from 


easy,  everyday  type  queries  to  hard,  unusual,  unlikely 


queries.  In  order  to  fully  test  the  system,  as  many 


possible  scenarios  as  feasible  should  be  presented  to  the 


system  with  the  system's  resulting  conclusions  compared 


against  expected  human  expert  generated  results. 


The  above  steps  are  iterative  and  earlier  steps  may 


need  rework  when  flaws  are  discovered  in  later  steps.  Since 


FRESH  is  being  developed  through  the  prototyping  technique. 


i.e.,  analyzing,  designing,  and  coding  a  small  set  of 


subproblems  (modules) ,  and  immediately  implementing  them 


into  the  prototype  expert  system,  this  see-saw  effect  of 


problem  identification  and  problem  solution  is  expected  to 


occur. 


E .  CHAPTER  SUMMARY 


To  better  help  the  reader  understand  FRESH,  this  chapter 


has  introduced  expert  systems  including  an  overview  of 


decision  theory,  expert  system  history  and  development, 


applications  of  expert  systems  in  the  world  today,  and  how 


knowledge  is  acquired  for  expert  systems, 
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III.  FRESH  AT  CINCPACFLT 


The  intent  of  this  chapter  is  to  provide  for  the  reader 
a  basic  understanding  of  the  CINCPACFLT  perspective  on 
FRESH.  This  includes  how  FRESH  was  developed,  how  it  is 
used,  and  its  input/output  requirements. 


A.  CINCPACFLT  GOALS  FOR  FRESH 

CINCPACFLT' s  goals  for  FRESH  are  to  use  it  as  an 
extremely  powerful  automated  aid  to  CINCPACFLT  personnel  in 
order  to: 

-  generate  Pacific  Fleet  unit  long  range  employment 
schedules. 

-  perform  as  a  tool  to  monitor  Fleet  readiness. 

-  determine  the  impact  of  changes  to  the  Fleet  (e.g., 
major  mission-degrading  casualty  to  a  ship) . 

-  generate  alternative  responses  to  these  changes  and 
recommend  appropriate  action. 

There  are  several  specific  goals  (see  Appendix  A)  for 
the  FRESH  prototype.  However,  the  most  important  is  to 
collapse  response  time  for  significant  planning/decision 
making,  and  allow  CINCPACFLT  personnel  to  make  faster 
decisions.  This  makes  sense,  since  as  noted  in  Chapter  II, 
one  of  the  major  reasons  for  an  expert  system  is  to  assist 
the  manager  in  making  decisions  as  quickly  as  possible. 


*  v'/.  a'a'aV.'a* 


,*-*.*;'#  *<  Mjk 


B.  FRESH  DEVELOPMENT 

FRESH,  an  expert  system  prototype  used  in  CINCPACFLT  to 
generate  Pacific  Fleet  ships  long  range  employment  schedules 
and  to  monitor  Fleet  readiness,  determine  the  impact  of 
changes  to  the  Fleet  (e.g.,  major  mission-degrading  casualty 
to  a  ship) ,  and  generate  alternative  responses  to  these 
changes,  is  being  developed  using  the  prototyping,  middle- 
out  approach  to  development.  This  method  of  development  as 
described  by  Peter  Keen,  starts  with  defining  what  the  user 
would  like  to  see  at  the  terminal  (CRT  screen  display) ,  then 
selecting  commands  and  verbs  familiar  to  the  user  (e.g., 
START,  READ,  QUIT) ,  and  lastly  implementing  these  commands 
into  Version  0 — the  first  prototype.  The  aim  is  to  support 
first,  extend  later.  In  other  words,  the  goal  of  the 
prototyping  method  is  to  try  to  give  the  users  something 
right  away  that  they  will  readily  accept,  and  then  to  add 
the  less  familiar,  more  complex  capabilities  later.  The 
term  middle-out  pertains  to  "beginning  close  to  the  level  of 
the  problem  at  hand,  and  it  involves  a  cyclical  process  of 
generalization  (bottom-up)  and  specifying  (top-down)  at  each 
stage  of  the  problem  solving  process"  [HURST  1983:124]. 

This  procedure  involves  continuous  feedback  between  the 
knowledge  engineer  and  the  user  expert  during  the  design  and 
implementation  process. 

The  prototyping  method  should  not  be  confused  with  the 
more  conventional  top-down  systems  analysis  and  design 


technique  which  involves  months  (or  even  years)  of  long, 
drawn  out,  analysis  and  design  for  each  and  every  module  of 
the  program  prior  to  implementation  [HURST  1983:125].  On 
the  other  hand,  the  prototyping  method  involves  analyzing, 
designing,  and  coding  a  small  set  of  subproblems  (modules) , 
and  immediately  implementing  them  into  the  prototype  expert 
system. 

These  so-called  subproblems  are  merely  pieces  (modules) 
of  the  pie  that  make  up  the  whole  expert  system  program.  The 
main  problem,  is  that  problem  for  which  the  system  has  been 
developed  to  solve. 

In  FRESH  the  main  problem  area  is,  "all  employment 
scheduling  related  problems,"  whereas  a  subproblem  (module) 
would  be,  "Can  ship  A  replace  ship  B?"  The  prototype  is 
quickly  developed  and  because  of  this  the  user  has  a  working 
product  (though  incomplete)  in  his  hands  much  faster  than  he 
could  ever  expect  using  the  thorough  step  by  step,  top-down 
systems  analysis  and  design  approach.  In  terms  of  FRESH, 
this  means  that  a  specific  subset  of  employment  scheduling 
problem  modules  were  tackled  first  and  implemented  into  the 
prototype.  As  development  proceeds  other  modules  are 
continually  being  added  and  this  process  will  continue  until 
FRESH  is  complete  i.e.,  contains  all  modules  encompassing 
the  total  employment  scheduling  problem.  According  to  Bui 
and  Sivasankaran  [SIVASANKARAN  1987:737]: 

...prototyping  consists  of  an  implementation  methodology 

that  focuses  on  the  effort  in  building  a  quick  and  working 


prototype  or  model  that  has  the  minimum  features,  and 
meets  the  basic  information  requirements. 


Charles  Rich  refers  to  this  process  as  "incremental 
automation"  [WINSTON  1984:132].  Both  the  user  and  the 
developer  are  expected  to  make  mistakes,  but  attempts  to 
learn  as  much  as  possible  from  these  mistakes  is  the  key  to 
making  the  prototyping  method  effective  [SIVASANKARAN  1987: 
737]  . 

FRESH,  since  it  is  still  in  the  prototype  stage  of  its 
development,  receives  new  software  updates  every  45-90  days. 
These  software  updates  include  both  new  modules  and  reworked 
existing  modules  (those  that  required  changes/updates) . 
Present  real-time  operational  uses  of  the  FRESH  prototype 
are  very  limited,  as  would  be  expected,  however  the  future 
holds  much  promise.  Both  present  and  future  uses  of  FRESH 
are  discussed  below  in  terms  of  the  major  reports  generated 
by  FRESH  and  the  major  queries  answered  by  FRESH. 

C.  FRESH  USES  AT  CINCPACFLT 

The  FRESH  uses  listed  below  are  highlighted  for 
illustration  purposes.  They  include  the  two  major  reports: 
Alert  Summaries  and  Long  Range  Employment  Schedules  and  some 
typical  ad  hoc  queries. 
i.  Alert  Suronaries 

FRESH's  current  primary  operational  duty  is  to 
produce  daily  Alert  Summaries  for  CINCPACFLT  staff  meetings. 
These  Alert  Summaries  provide  a  listing  of  operational  units 
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having  a  Combat  Readiness  Rating  of  C3  or  C4  (marginally 
combat  ready  or  not  combat  ready  respectively)  [NWP-io-1-11 
1985:34].  An  Alert  Summary  is  generated  when  a  unit  fails 
to  meet  certain  thresholds  for  Mission/Combat  Readiness,  the 
specifics  of  Alert  Summary  Generation  are  outlined  in  Figure 


when  a  unit  submits  a  deficiency  report,  this  report 
contains  a  numerical  value  for  the  area  of  degradation 
— overall  combat  readiness,  primary  mission,  equipment, 
personnel,  training,  support,  and  each  applicable 
secondary  mission. 

FRESH  compares  this  numerical  value  (provided  by  the 
unit)  to  the  threshold  table  value  that  was  previously 
constructed  from  data  provided  by  the  user. 

when  a  unit's  readiness  value  in  one  of  the  specified 
areas  e.g.,  overall  combat  readiness,  primary  mission 
readiness  (equipment,  personnel,  training,  support)  or 
applicable  secondary  mission,  is  equal  to  or  less  than 
the  user  provided  threshold  value,  an  alert  is 
generated. 


Figure  3-1  Causes  of  Alert  Summary  Generation 


The  threshold  values  mentioned  above,  are  at 
present,  expressly  for  the  unit's  primary  mission  area.  They 
are  set  to  generate  an  alert  if  a  unit  is  above  its 
threshold  for  either  an  input  Casualty  Report  (CASREP)  or  an 
input  Unit  Status  and  Identity  Report  (UNITREP) .  In  essence 
the  given  threshold  can  be  thought  of  as  the  equipment, 
personnel,  training,  and  support  required  to  effectively 
fulfill  the  primary  mission  area.  Degradations  affecting 
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equipment,  personnel,  training,  and  support  required  to 
effectively  fulfill  the  primary  mission  area  are  reported  by 
either  UNITREP,  CASREP  or  both. 

FRESH  has  the  capability  for  the  user  to  set 
threshold  values  for  secondary  mission  areas  but  this  is  not 
currently  done  as  there  appears  to  be  little  CINCPACFLT 
interest  in  monitoring  secondary  mission  areas  on  a  general 
basis.  Once  the  ability  of  FRESH  to  correctly  identify 
significant  events  is  proven  to  the  CINCPACFLT  staff,  an 
interest  in  monitoring  secondary  mission  areas  may  be  seen. 

It  should  be  noted  that  the  threshold  values  may  be 
changed  dynamically,  i.e.,  by  the  user  at  any  time  prior  to 
a  FRESH  run.  These  threshold  values  are  the  basis  for 
generating  unit  replacements  when  a  unit  must  be  replaced  to 
meet  an  operational  commitment.  To  illustrate  this,  if  an 
anti-aircraft  unit  reported  a  Combat  Readiness  Rating  of  C4 
(not  combat  ready)  and  consequently  had  to  be  replaced  to 
meet  an  operational  commitment,  the  FRESH  user  would  put  a 
high  threshold  number  in  the  anti-aircraft  primary  mission 
area  threshold  table.  Thus  in  order  for  a  unit  to  be 
selected  to  replace  the  above  C4  unit,  it  would  have  to  have 
to  meet  the  high  anti-aircraft  capability  threshold 
specified  by  the  FRESH  user. 

At  first  glance  this  Alert  Summary  sounds  as  if  it 
would  be  quite  valuable,  but  the  Alert  Summary  lacks 
sufficient  data  to  make  it  a  useful  document.  The  Alert 


Summary  does  not  state  what  is  driving  the  high  Combat 
Readiness  Rating — the  CINCPACFLT  staff  only  knows  that 
SOMETHING  is  wrong,  they  don't  know  WHAT  is  wrong.  This 
lack  of  sufficient  knowledge  forces  the  CINCPACFLT  staff  to 
conduct  further  research,  through  FRESH,  to  determine  the 
cause  of  the  high  Combat  Readiness  Rating  (reasons  can  range 
from  the  ship  having  a  major  equipment  failure  to  only 
lacking  training  in  a  particular  area) .  This  apparent 
breakdown  of  the  knowledge  engineering  system  can  be 
attributed  to  either  problems  in  the  Formalization  Phase 
(refinement  of  subproblems)  or  the  Implementation  Phase 
(integrating  knowledge  into  the  computer  representational 
framework)  [HAYES-ROTH  1983:144-146].  It  is  not  the  intent 
of  this  research  to  fix  blame.  CINCPACFLT  personnel  are 
working  to  change  the  Alert  Summary  Report  to  include  the 
reason  for  the  poor  Combat  rating. 


Long  Range  Employment  Schedule  production  is  in  its 
infancy.  Manually  produced  Quarterly  Employment  Schedules 
are  used  as  the  primary  input.  Then  FRESH  focuses  on  the 
major  ship  in  the  battle  group,  for  example  the  carrier  in  a 
Carrier  Battle  Group,  and  bases  the  Long  Range  Employment 
Schedule  on  this  particular  platform's  long  range 
maintenance  schedule.  The  same  procedure  is  followed  for 
Amphibious  Ready  Groups,  Battle  Ship  Battle  Groups,  Cruiser 
Battle  Groups,  etc.  This  long  term  scheduling  system  appears 
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to  be  very  weak  in  terms  of  making  effective  use  of  FRESH 
technology,  too  much  up  front  manual  work  is  required  to 
prepare  Quarterly  Employment  Schedule  input  to  FRESH  (it  may 
take  weeks  or  months  to  manually  produce  the  Quarterly 
Employment  Schedules) .  One  flaw  appears  to  be  the  large 
amount  of  manual  labor  required  to  produce  this  Long  Range 
Employment  Schedule.  This  flaw  is  serious  because  it  is  in 
direct  conflict  with  the  reason  for  having  a  computer  system 
— to  reduce  the  amount  of  human  manual  work  that  is 
required. 

Another  apparent  flaw  is  that  basic  assumptions  have 
been  made  are  not  always  true,  for  example  the  assumption 
that  all  members  of  a  battle  group  will  always  deploy 
centered  around  the  same  major  combatant  (e.g.,  carrier)  is 
not  a  good  long  range  planning  assumption.  Why?  Because  a 
Destroyer's  maintenance  requirements  are  not  the  same  as  the 
carrier  that  it  deploys  with.  This  lack  of  concern  for  the 
"small  boys"  seems  to  be  the  weakest  link  in  the  system. 

The  only  platform  with  a  valid  Long  Range  Employment 
Schedule  would  be  the  platform  that  the  battle  group  is 
formed  upon.  The  'small  boys'  Long  Range  Employment 
Schedule  might  be  in  sync  with  the  major  combatant  for  the 
first  year  but  little  credibility  can  be  given  to  the 
schedule  for  the  out  years  unless  of  course  CINCPACFLT 
makes  it  a  hard  and  fast  requirement  that  battle  group 
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composition  remain  constant — an  unrealistic  and  hard  task  to 
manage . 


This  is  the  area  in  which  FRESH  shines.  The 
scheduling  scenarios  that  can  be  set  up,  projected,  changed, 
and  tested  appear  almost  limitless.  Specific  examples  of 
FRESH  ad  hoc  queries  and  respective  outputs  will  be  provided 
later  in  this  chapter.  It  is  obvious  to  any  user  that  the 
FRESH  prototype  is  not  effective  in  producing  employment 
schedules  (see  above) ,  rather  FRESH  is  an  extremely  powerful 
tool  when  tasked  to  manipulate  employment  schedules  and 
answer  'What  if'  types  of  questions. 

For  example,  if  an  Aegis  Class  Cruiser  is  unable  to 
deploy  with  its  battle  group,  what  will  be  the  impact  on 
battle  group  readiness?  Do  we  need  to  replace  the  missing 
ship?  If  there  is  not  another  available  Aegis  Class  Cruiser 
can  we  get  a  comparable  platform  to  replace  it?  What 
weapons  and  resources  will  be  needed  to  offset  the  loss  of 
the  Cruiser?  Queries  presently  may  only  involve  a  single 
unit  (ship  or  submarine)  however  in  the  future  FRESH  will 
hopefully  be  able  to  evaluate  the  overall  capacity  of  an 
entire  battle  group  [DELEOT  1987:2].  Queries  such  as — "How 
long  will  it  take  to  move  a  ship  from  point  A  to  point  B?" 
can  also  be  answered.  FRESH  is  very  powerful  in  its  ability 
to  work  out  hypothetical  situations  without  interfering  with 
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the  real  world,  i.e.,  without  interfering  with  the  actual 
data  in  the  FRESH  database. 

D.  PROBLEMS  WITH  FRESH  AT  CINCPACFLT 
1.  Database 

a.  General  Problems 

The  database  is  to  some  extent  not  qualitatively 
correct.  Through  discussions  with  CINCPACFLT,  Texas 
Instruments  and  BTG  representatives  and  likewise  through  the 
author's  observations,  it  was  noted  that  the  database 
contains  both  duplicate  and  incorrect  data.  CINCPACFLT 
personnel  further  stated  that  there  are  empty  fields  within 
the  relations  in  the  database  and  that  modification, 
insertion  and  deletion  anomalies  [KROENKE  1983:287]  are 
present. 

This  leads  one  to  believe  that  the  data  found  in 
FRESH's  relational  database  is  not  correctly  normalized. 
Rather,  the  normalization  rules  which  are  designed  to 
prevent  update  anomalies  and  data  inconsistencies  are  not  at 
a  sufficient  level  to  preclude  serious  problems  with  the 
FRESH  database.  In  order  for  FRESH  to  become  a  viable, 
usable  tool  this  database  must  be  redesigned  to  meet  at 
least  fifth  normal  form  (when  a  record's  information  content 
cannot  be  reconstructed  from  several  smaller  record  types 
[KENT  1985:120])  and  be  filled  with  correct  data. 
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b.  Configuration  Data  Problems 

FRESH  contains  configuration  data  within  its 
database.  This  configuration  data  outlines,  among  other 
things,  which  equipment  is  installed  on  which  unit.  Through 
close  observation,  it  is  readily  apparent  that  incorrect 
data  is  rampant  in  this  portion  of  the  database.  The 
configuration  data  on  file  was  provided  by  the  Naval  Ocean 
Systems  Center  (NOSC) ,  San  Diego  and  was  based  on  the 
configuration  of  the  lead  ship  in  a  class  of  ships  e.g.,  all 
Spruance  Class  Destroyers  have  the  same  configuration  data 
as  that  found  on  file  for  the  U.S.S.  Spruance.  It  is 
assumed  that  the  lead  ship's  configuration  data  was  obtained 
from  the  Weapons  Systems  File  which  is  the  master  configura¬ 
tion  file  for  all  United  States  Ships  and  Submarines  [NSCS 
1983:1.6-2] . 

This  generalization  that  all  ships  in  a  class 
have  identical  configuration  is  grossly  incorrect  and  in 
fact  the  Navy  Ships  Parts  Control  Center  in  Mechanicsburg, 

PA  (the  maintainer  of  the  Weapons  Systems  File)  feels  that 
after  five  years  from  the  start  of  construction  of  a  new 
class  of  ships,  at  most,  50%  of  the  equipments  found  on  the 
lead  ship  are  common  equipments  on  follow  on  ships  of  the 
class.  CINCPACFLT  personnel  are  aware  of  the  problem  and 
are  seeking  new  avenues  for  the  submission  of  configuration 
data,  however  it  is  the  author's  belief  that  FRESH  should 
utilize  Level  A  (unit  to  installed  equipment  on  unit)  of  the 


Weapons  Systems  File  as  the  basis  for  this  configuration 
data.  Although  it  is  commonly  known  that  the  Weapons 
Systems  File  is  not  100%  complete,  it  is  the  best 
configuration  file  available. 

2 .  Testing 

According  to  Texas  Instruments  and  BTG 
representatives,  it  is  extremely  difficult,  if  not 
impossible,  to  fully  test  out  a  module  of  FRESH  code.  In 
large  part  this  problem  exists  simply  because  the  number  of 
queries  that  can  be  made  of  an  individual  module  of  code  is 
practically  unlimited.  In  a  problem  related  to  the  database 
issue,  when  problems  are  found  it  is  difficult  to  pinpoint 
if  the  fault  resides  in  FRESH  or  in  the  database.  This 
results  in  almost  doubling  of  the  time  required  to  find  the 
solution  to  a  surfaced  problem. 


FRESH  has  problems,  but  once  detected,  these 
problems  are  being  attacked  with  a  vigor.  The  major 
drawback  in  the  FRESH  implementation  is  without  a  doubt  the 
database  issue  noted  above.  Until  the  FRESH  database  is 
fixed,  FRESH  development  will  continually  be  hampered  by 
problems  caused  by  bad  data. 


E.  CINCPACFLT  FRESH  EXTERNAL  SYSTEM  INPUTS 

It  is  apparent  that  the  most  important  input  to  FRESH  is 
the  present  geographical  position  of  a  unit.  This 
geographic  position  can  be  input  to  FRESH  by  Casualty 
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Report,  Unit  Status  and  Identity  Report,  Movement  Report, 
Pacific  Advanced  Command  Exchange  (PACACE) ,  and  unit 
submitted  weather  report  messages.  The  most  recent 
geographical  position  data  (regardless  of  input  mode)  will 
automatically  update  the  FRESH  database. 

Unless  otherwise  stated  in  the  narrative,  the  below 
inputs  are  standard  all-Navy  reports,  i.e.,  they  are  used  on 
both  Atlantic  and  Pacific  coasts  and  therefore  would  not 
require  change  in  order  to  transport  FRESH  from  CINCPACFLT 
to  CINCLANTFLT.  A  summary  of  FRESH  external  system  inputs 
is  shown  in  Figure  3-2. 


REAL-TIME  LOAD — PACACE  (Blue  Positional  Reports) ,  FOSIC 
(Red  Positional  Reports) 

WWMCCS  LOAD— UNI TREP  (subset).  Ship's  Positional  data 
( Departure  Report ,  etc . ) 

TAPE  LOAD  (twice/week) — Weapons  Loadout,  Quarterly 
Employment  Schedule 

TAPE  LOAD  (Quarterly) — Configuration  data  from  NOSC 

MANUAL  LOAD — CASREP  data,  MOVREP  data 

FUTURE  INPUT — Port  Information,  Routing  Information. 


Figure  3-2  FRESH  System  Inputs 


1.  Real-time  Computer  Input 

a.  Pacific  Advanced  Command  Exchange  (PACACE) 
This  is  a  Pacific  Fleet  Integrated  Tactical 
Decision  Aid  that  assists  the  Battle  Group  Commander  in 


JSWWwW 


rapidly  assessing  threat  information.  It  is  used  as  a  FRESH 
input  to  provide  geographic  positions  of  U.S.  Forces, 
otherwise  known  as  Blue  Positionals.  When  PACACE  reports 
are  received  at  CINCPACFLT,  unit  positional  information  is 
gleaned  from  them  and  is  placed  in  the  FRESH  database.  The 
Atlantic  Fleet  counterpart  of  this  system  is  called  the 
Joint  Operational  Tactical  System  (JOTS) .  According  to 
CINCPACFLT,  JOTS  and  PACACE  are  the  same  system  they  simply 
have  different  names  on  the  different  coasts. 

b.  Fleet  Ocean  Surveillance  Information  Center 

Reports 

The  Fleet  Ocean  Surveillance  Information  Center 
(FOSIC)  provides  CINCPACFLT  with  position  information  on 
Soviet,  Chinese,  Vietnamese,  North  Korean,  and  other 
unfriendly  forces,  otherwise  known  as  Red  Positionals. 

FOSIC  reports  ensure  appropriate  early  warning  to  the 
Seventh  Fleet  Commander  and  to  the  Commander  of  the  Middle 
East  Force  (COMSEVENTHFLT  and  COMMIDEASTFOR  respectively) 
regarding  high  interest  or  threat  activity  for  the  assigned 
areas  of  responsibility  [COMSEVENTH  1984].  These  Red 
Positional  reports  are  likewise  fed  into  the  FRESH  database. 


2. 


VTTTT*  vCL!  *  [■  •lHKi  <0 1  il  *!• 


I'K-n- 


e 


every  six  hours.  A  UNITREP  is  submitted  to  inform  the 
National  Command  Authority  of  changes  to  unit  identifica¬ 
tion,  location,  general  status,  current  unit  activity  and 
employment,  weapons  load  out  and  combat  readiness 
information  [NWP-10-1-11  1985].  As  far  as  FRESH  is 
concerned,  UNITREP  presently  only  provides  the  geographical 
position  of  the  unit  and  the  combat  readiness  rating  which 
FRESH  compares  against  the  threshold  values  loaded  into  the 
system  by  the  FRESH  user. 

The  subset  of  UNITREP  data  is  automatically 
accepted  by  the  FRESH  database  (the  geographical  position  of 
the  unit  and  the  combat  readiness  rating) .  This  UNITREP 
data  oversight  was  an  interface  design  omission  and  BTG  Inc. 
is  working  to  correct  this  deficiency — most  data  found  on 
UNITREP  is  important  to  FRESH  (especially  the  weapons  load 
out)  and  should  be  included  within  the  FRESH  database. 
Further  discussion  below  will  identify  how  other  UNITREP 
data  (not  included  in  the  WWMCCS  subset)  is  loaded  into 
FRESH  today  'manually. ' 

b.  Ship's  Position  Reports 

This  standard  Navy  report  simply  depicts  a 
unit's  geographical  position.  A  common  example  of  a 
positional  report  is  a  Departure  Report  which  a  unit  submits 
just  as  it  leaves  a  port.  There  are  also  reports  which  must 
be  submitted  when  entering  a  port.  This  data  updates  a 
unit's  geographical  position  within  the  FRESH  database. 
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3 .  Magnetic  Tape  Load  (Twice  Per  Week 


a.  Weapons  Load  Out 

This  is  one  of  the  data  fields  that  should  be 
automatically  updated  via  the  UNITREP,  but  due  to  the 
interface  design  mentioned  above,  it  was  left  out  and  now 
must  be  manually  gleaned  from  UNITREP,  put  on  tape,  and 
loaded  to  FRESH  twice  a  week.  This  weapons  load  out  depicts 
significant  weapons  that  a  unit  presently  holds.  This 
information  is  important  in  both  a  strategic  and  tactical 
sense. 

b.  Unit  Employment  Schedule 

This  information  is  prepared  at  CINCPACFLT 
Headquarters  and  is  based  on  what  a  unit  is  scheduled  to  do 
and  is  updated  based  on  what  the  unit  is  actually  doing. 
Dynamic  changes  due  to  real  world  requirements,  often  change 
the  employment  schedule  already  on  file.  This  employment 
schedule  data  is  used  as  a  basis  for  update  changes  to  a 
units  future  employment. 
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a.  Unit  Configuration  Data 

This  data  is  provided  by  the  Naval  Ocean  Systems 
Center  (NOSC) ,  San  Diego  and  is  used  to  update  unit 
configuration  (which  units  have  which  weapons  systems)  in 
the  FRESH  database.  Problems  with  this  data  are  outlined 
above.  This  data  includes  listings  of  the  unit's  installed 
equipment,  specific  characteristics  of  the  equipment  such  as 


Pjl 

| 


LVjTR.'A'V.  WJ  wvww.i 


associated  signals  and  effective  ranges,  and  unit  fuel  usage 
statistics.  In  contrast  to  the  Weapons  Loadout,  Unit 
Configuration  Data  may  be  thought  of  as  a  unit's  installed 
equipments  i.e.,  a  specific  radar  or  gun  fire  control  system 
that  is  organic  to  the  unit  as  opposed  to  a  specific  special 
weapon  not  always  found  on  a  unit  e.g.,  Harpoon  Missiles, 
which  might  be  placed  on  a  unit  for  a  specific  evolution; 
these  would  be  noted  in  the  Weapons  Loadout. 


a.  Casualty  Report  Data 

A  Casualty  Report  (CASREP)  is  used  to: 
a)  report  an  initial  equipment  casualty,  b)  update  the  chain 
of  command  on  the  status  of  the  casualty  and  c)  report  that 
the  casualty  has  been  corrected.  Through  CASREP,  the  chain 
of  command  is  advised  of  significant  equipment  malfunctions 
which  may  result  in  the  degradation  of  a  unit's  readiness 
[NWP-7  1984:B-1].  FRESH  uses  the  mission  rating  provided  by 
CASREP  to  compare  against  the  mission  rating  thresholds 
already  established  for  the  given  unit.  This  data  is 
manually  loaded  as  soon  as  it  is  received  from  the  fleet. 
CASREP  data  is  scheduled  to  be  loaded  realtime,  via  the 
World  Wide  Military  Command  and  Control  System  (WWMCCS)  in 
the  summer  of  1988. 

b.  MOVREP  Data 

A  Movement  Report  (MOVREP)  in  general  is  used  to 
report:  a)  a  departure  from  port,  b)  an  arrival  into  port, 
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and  c)  the  intended  courses  and  speeds  a  unit  anticipates 
using  while  going  between  point  A  and  point  B  [NWP-7  1984: 
11-1].  Likewise,  if  there  is  a  change  to  a  unit's  planned 
movement  a  MOVREP  would  be  required.  FRESH  uses  this  data 
to  update  unit  position.  Like  CASREP,  this  data  is  manually 
loaded  as  soon  as  it  is  received  from  the  fleet  and  is 
scheduled  to  be  loaded  realtime,  via  the  World  Wide  Military 
Command  and  Control  System  (WWMCCS)  in  the  near  future. 

c.  Personnel  Tempo  and  Operational  Tempo  Data 

The  Chief  of  Naval  Operations  has  established  a 
policy  regarding  the  maximum  duration  of  time  that  a  ship 
may  spend  away  from  homeport.  In  terms  of  personnel,  this 
is  referred  to  as  PERSTEMPO  and  in  terms  of  the  operating 
unit  this  is  called  OPTEMPO.  The  OPTEMPO/ PERSTEMPO  policy 
was  developed  in  response  to  sagging  morale  and  lower 
retention  that  was  thought  to  have  been  caused  by  arduous, 
extended  deployments.  Because  of  this  policy,  the  FRESH 
database  includes  OPTEMPO/ PERSTEMPO  information,  e.g.,  start 
date  of  a  unit's  deployment.  This  OPTEMPO/ PERSTEMPO  data  is 
used  to  ensure  that  units  do  not  exceed  the  six  month 
deployment  length  maximum  and  that  units  in  fact  exhibit  a 
two  for  one  turnaround  time  between  deployments  (six  months 
deployed,  twelve  months  operating  out  of  homeport) .  There 
are  several  other  OPTEMPO/ PERSTEMPO  constraints  included  in 
the  FRESH  unit  replacement  algorithm  however  inclusion  in 
this  thesis  is  unnecessary.  Suffice  it  to  say  that 
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OPTEMPO/PERSTEMPO  restrictions  play  a  significant  role  when 
FRESH  performs  analysis  to  determine  replacement  units. 


d.  Fuel  Cost  Information 

Fuel  costs,  per  barrel,  are  loaded  into  the 
FRESH  database  and  are  used  in  concert  with  the  fuel  usage 
data  already  in  FRESH  to  calculate  the  fuel  cost  that  will 
be  incurred  by  unit  replacement,  e.g.,  if  several  unit 
replacement  candidates  are  generated  by  FRESH,  which  one 
will  cost  the  least  (in  terms  of  fuel)  to  transit  to  the 
required  area? 

6.  Future  FRESH  Inputs 

a.  Port  to  Port  Routing  Data 

This  routing  information  will  include  the  most 
efficient  land  avoidance  routes  between  any  two  Pacific 
ports.  Route  efficiency  will  be  determined  based  on  fuel 
costs,  weather,  and  avoidance  of  areas  of  hostility. 

b.  Western  Pacific  Port  Data 

Information  on  Western  Pacific  (WESTPAC)  ports 
will  include  descriptions  of  fuel  facilities,  drydock 
facilities,  repair  facilities,  etc.  The  value  of  this  data 
should  be  obvious,  if  CINCPACFLT  is  required  to  divert  a 
unit  into  port  because  of  an  equipment  casualty,  they  must 
be  able  to  readily  assess  the  location  of  the  nearest  port 
that  can  effect  the  required  repairs. 


F.  CINCPACFLT  FRESH  EXTERNAL  SYSTEM  OUTPUTS 


1.  Alert  Summaries 

As  noted  above,  FRESH  provides  Alert  Summaries  as 
they  occur.  Alert  Summaries  provide  a  listing  of 
operational  units  having  a  Combat  Readiness  Rating  of  C3  or 
C4  (marginally  combat  ready  or  not  combat  ready 
respectively)  [NWP-10-1-11  1985],  and  are  used  in  the  daily 
flag-level  brief  to  the  CINCPACFLT  staff. 

2 .  Long  Range  Employment  Schedules 

Long  Range  Employment  Schedules  reflect  the 
timeframes  and  sequencing  of  all  major  predeployment 
evolutions  for  a  unit  over  a  five  year  time  period. 

According  to  the  available  FRESH  documentation,  Long  Range 
Employment  Schedules  are  supposed  to  be  used  as  the  basis 
for  building  the  quarterly  employment  schedule.  However, 
after  questioning  CINCPACFLT  personnel,  it  was  readily 
apparent  that  presently  FRESH  performs  just  the  opposite, 
i.e.,  FRESH  determines  Long  Range  Employment  Schedules  based 
on  the  manually  produced  quarterly  employment  schedule.  The 
author  feels  and  CINCPACFLT  personnel  agree,  that  FRESH  is  a 
long  way  from  reaching  the  point  of  producing  automated 
quarterly  employment  schedules  based  on  the  Long  Range 
Employment  Schedule.  Presently,  FRESH  updates  Long  Range 
Employment  Schedules  as  changes  occur  and  these  new 
schedules  are  distributed  to  those  requiring  the 
information.  Problems  with  the  Long  Range  Employment 
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Schedule  as  generated  by  FRESH  are  discussed  above  in 
Section  C.2. 

3 .  Alternative  Unit  Replacement 

When  a  unit  experiences  a  degradation  which 
precludes  it  from  carrying  out  its  mission,  replacement 
units  are  generated  by  FRESH.  These  replacement  units  are 
ranked  according  to  their  ability  to  fulfill  the  required 
mission  and  FRESH  will  provide  a  rational  explanation  as  to 
why  replacement  units  were  ranked  as  they  were.  The  user 
can  also  query  FRESH  as  to  the  impact  of  selecting  a 
specific  replacement  unit,  e.g.,  what  missions  will  the 
replacement  unit  be  unable  to  perform  as  a  result  of  the 
redirection? 

4.  Geographic  Displays 

FRESH  allows  the  user  to  view  geographic  displays  of 
the  Pacific  using  a  mercator  projection,  a  stereographic 
projection,  a  gnomonic  projection  or  a  true  view  projection. 
On  these  geographic  displays,  the  user  may  view  any  or  all 
units'  current  positions  (based  on  latest  geographical 
position  submitted) ,  future  positions,  past  and  future 
tracks,  and  land  avoidance  routes  (yet  to  be  implemented) . 

5.  Contexts 

The  term  contexts  refers  to  FRESH's  ability  to 


answer  queries  based  on  an  artificial  situation,  a  "what  if" 
situation.  Examples  include: 


-  what  if  ship  A  replaced  ship  B? 

-  what  if  ship  A  were  equipped  with  equipment  C? 

-  what  if  ship  A  had  a  C-4  CASREP  (equipment  inoperable)? 

-  what  if  the  overall  combat  readiness  of  ship  A  was  C4? 

-  what  if  the  fleet  wide  OPTEMPO  changed  to  _ ? 

-  what  if  the  fleet  wide  PERSTEMPO  changed  to  _ ? 

6.  Calculations 

FRESH  has  the  ability  to  calculate  the  fuel  cost  of 
moving  a  unit  from  position  A  to  position  B.  It  can 
likewise  compute  the  OPTEMPO,  turnaround  time,  or  deployment 
time  (duration)  of  a  unit. 

7 .  Database  Queries 


The  user  may  query  the  FRESH  database  to  find  out 
information  on  specific  units,  type  and  number  of 
weapon (s) /equipment (s)  carried  on  a  unit,  and  specific 
characteristics  such  as  associated  signals,  effective 
ranges,  etc.  Many  examples  are  included  in  appendices  B  and 
C.  However,  to  give  the  reader  a  flavor,  the  following 
examples  are  provided: 

-  list  the  associated  signals  of  radar  A. 

-  list  all  CASREPs  for  a  ship. 

-  list  the  Anti  Air  Warfare  rating  of  all  applicable  ships 
in  CTF-75. 

-  list  positions  of  one  or  more  units. 

-  list  all  ships  equipped  with  the  Harpoon  missile  system. 

-  list  the  readiness  history  of  a  ship. 


The  above  mentioned  FRESH  outputs  are  by  no  means  to 


be  considered  all  encompassing.  The  intent  of  the  queries 
cited  is  to  give  the  reader  a  broad  view  of  the  power  of 
FRESH.  The  knowledgeable  user  of  FRESH  will  possess  an 
almost  limitless  ability  to  query  the  expert  system 
regarding  any  of  the  attributes  mentioned  above. 

G.  CHAPTER  SUMMARY 

This  chapter  built  upon  the  expert  system  theory 
foundation  provided  in  Chapter  II  by  depicting  an  actual 
expert  system — FRESH.  Specific  topics  included — FRESH's 
prototype  method  of  development,  FRESH's  use  of  the 
knowledge  engineering  method  of  knowledge  acquisition, 
problems  experienced  with  both  prototyping  and  knowledge 
engineering,  uses  of  FRESH  at  CINCPACFLT,  and  FRESH's 
required  inputs/ outputs. 

This  now  leads  us  to  Chapter  IV  where  CINCLANTFLT ' s 
existing  unit  scheduling  system  will  be  discussed  and 
contrasted  with  that  provided  by  the  expert  system  FRESH  in 
CINCPACFLT.  Specifically,  CINCLANTFLT ' s  unit  scheduling 
system  inputs  and  outputs  will  be  contrasted  with  those  of 
CINCPACFLT,  which  have  already  been  listed. 
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IV.  CINCLANTFLT  PERSPECTIVE — CAN  FRESH  HELP? 


The  basic  goal  of  this  thesis  is  to  identify  differences 
between  CINCPACFLT  and  CINCLANTFLT  inputs  and  outputs 
associated  with  FRESH.  Chapter  III  presented  the  CINCPACFLT 
story.  Now  CINCLANTFLT ' s  perspective  will  be  presented. 

This  view  will  include  the  inputs  CINCLANTFLT  uses  to 
manually  produce  Long  Range  Employment  Schedules,  how 
rescheduling  of  ships  occurs  when  casualties  arise,  and 
outputs  that  CINCLANTFLT ' s  manual  system  generates  that 
would  be  considered  essential  to  be  produced  by  FRESH  were 
it  to  be  transported  to  CINCLANTFLT. 

CINCLANTFLT  is  extremely  interested  in  FRESH,  in  fact, 
since  beginning  this  research,  CINCPACFLT  and  CINCLANTFLT 
staffs  have  met  regarding  FRESH.  The  Atlantic  personnel 
have  been  impressed  with  FRESH's  performance  and  its 
possibilities.  Because  of  this,  there  is  little  doubt  that 
FRESH  will  eventually  be  transferred  to  CINCLANTFLT  if 
Congress  provides  funding.  (In  light  of  present  budget 
constraints  this  funding  may  not  materialize.) 


A.  CINCLANTFLT  EMPLOYMENT  SCHEDULING  SYSTEM  OVERVIEW 
Unlike  CINCPACFLT’ s  scheduling  operation,  with  its 
automated  support  through  FRESH,  CINCLANTFLT ' s  employment 
scheduling  system  is  highly  manual,  requiring  several 
full-time  scheduling  officers  and  additional  personnel  at 


various  levels  of  management,  with  little  computer 
assistance  provided.  Their  approach  to  building  unit 
employment  schedules  is  similar  to  CINCPACFLT's  in  that  it 
is  a  bottom  up  as  well  as  a  top  down  approach.  Input  is 
received  from  the  unit's  respective  Type  Commander 
(Commander  Naval  Surface  Forces  Atlantic,  Commander  Naval 
Air  Forces  Atlantic  or  Commander  Naval  Submarine  Forces 
Atlantic),  Group  Commanders,  Squadron  Commanders  and  the 
individual  Unit  Commanders  themselves  and  goes  up  through 
the  chain  of  command  to  CINCLANTFLT.  Likewise,  requirement 
inputs  are  pushed  down  the  chain  of  command  to  CINCLANTFLT 
from  the  Secretary  of  Defense  (SECDEF)  and  Chief  of  Naval 
Operations  (CNO) .  The  collection  of  these  inputs  culminates 
in  the  quarterly  scheduling  conference  (chaired  by 
CINCLANTFLT)  where  the  actual  quarterly  employment  schedules 
are  manually  constructed.  In  the  overall  process,  computers 
are  only  used  to  store  and  retrieve  schedule  data;  they  are 
not  used  in  any  way  to  assist  in  the  decision  making  process 
[GOODMAN  1985:9],  CINCPACFLT's  employment  scheduling 
process  is  somewhat  more  geared  toward  the  bottom  up 
approach,  i.e.,  requirements  are  initially  submitted  by  the 
unit  itself  and  additional  requirements  (including  required 
maintenance)  are  added  as  the  schedule  works  its  way  up 
through  the  chain  of  command.  Then  at  the  CINCPACFLT  level, 
SECDEF  and  CNO  requirements  are  added. 


B.  CINCLANTFLT  NAVAL  UNIT  CONTROL 


It  appears  that  scheduling  and  control  of  the  Naval 
units  on  the  Atlantic  coast  is  somewhat  more  decentralized 
than  on  the  Pacific  coast.  Although  the  author  at  first 
thought  that  this  policy  might  have  been  a  result  of  the 
existence  of  FRESH  at  CINCPACFLT  headquarters,  this  proved 
to  be  untrue.  CINCPACFLT  personnel  state  that  this 
"centralization  of  control"  is  just  PACFLT  tradition.  In 
any  case,  scheduling  and  control  in  the  Atlantic  is  more 
decentralized  than  in  CINCPACFLT. 

C.  CINCLANTFLT  EMPLOYMENT  SCHEDULE  INPUTS 1 
1.  Maintenance  Schedules 

These  schedules  include  major  maintenance/ overhaul 
schedules,  new  construction  vessels  available,  units  that 
will  undergo  inactivation  during  the  timeframe  concerned, 
minor  maintenance/post  overhaul  availablilities,  selected 
restricted  availabilities,  and  intermediate  maintenance 
availabilities. 

Maintenance  schedules  are  maintained  and  promulgated 
by  the  unit's  type  commander  in  both  the  Atlantic  and 
Pacific  fleets. 


■^CINCLANTFLT  inputs  to  the  employment  scheduling 
process  were  solicited  via  correspondence  and  the  response 
received  was  in  terms  of  the  Commander  Submarine  Forces 
Atlantic  perspective  (considered  representative  of 
CINCLANTFLT) .  All  inputs  are  manually  generated  and 
submitted . 
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2 .  Unit  Deployment  Requirements 

This  category  of  input  includes  both  mandatory 
deployments,  i.e.,  those  that  have  been  dictated  by  higher 
command  and  must  be  undertaken,  and  discretionary 
deployments,  i.e.,  things  that  they  would  like  to  have  done 
— usually  proposed  via  lower  levels  in  the  chain  of 
command. 

This  process  is  conducted  in  the  same  fashion  in 
both  PACFLT  and  LANTFLT. 

3 .  Personnel  Tempo  and  Operational  Tempo 

In  the  process  of  determining  the  required 
deployments  mentioned  above,  Personnel  Tempo  and 
Operational  Tempo  (PERSTEMPO/OPTEMPO)  are  also  considered. 

As  outlined  earlier,  the  Chief  of  Naval  Operations  has 
established  an  all-Navy  policy  regarding  the  maximum 
duration  of  time  that  a  ship  and  it's  personnel  may  spend 
away  from  homeport.  This  is  termed  PERSTEMPO/OPTEMPO.  This 
policy  applies  to  both  CINCLANTFLT  and  CINCPACFLT  in 
exactly  the  same  way  and  is  further  described  in  Chapter 
III. 

4.  Unique  Material  Conditions 

In  this  category  of  deployment  scheduling, 
CINCLANTFLT  considers  the  class  of  the  ship  and,  the  combat 
systems  configuration  e.g.,  specific  sonar,  fire  control 
system,  and  electronics  surveillance  system  on  specific 
units,  the  unit's  weapons  capability,  the  unit's  speed 
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capability,  fuel  limits  etc.  In  addition  to  those  material 
conditions  which  strictly  deal  with  a  units  material 
configuration,  CINCLANTFLT  likewise  considers  the  unit's 
Commanding  Officer's  deployment  experience,  and  the  crews 
overall  deployment  experience. 

5 .  Manor  Unit  Exercise  Requirements 

These  exercise  requirements  include  the  minimum  and 
maximum  participation  expected  for  NATO  Exercises,  Joint 
Exercises,  Fleet  Exercises  and  Type  Commander  Exercises. 

6 .  Major  Unit  Inspections 

This  input  is  received  by  all  commands  that  could 
possibly  inspect  a  unit  during  the  year.  The  type  of 
inspection  that  is  scheduled  can  range  from  supply 
inspections  to  nuclear  material  security  inspections.  Also 
included  in  this  category  would  be  live  weapon  firing  for 
proficiency  testing. 

7 .  Desired  Evolutions  of  Unit 

This  input  defines  the  activities  that  the  unit 
commander  would  like  to  perform  during  the  scheduled  time 
period;  they  include  changes  of  command,  dependent  cruises, 
desired  periods  at  sea,  desired  periods  inport,  desired 
port  visits,  etc. 

8.  Fleet  Services  Requested 

These  are  services  that  are  requested  by  the 


numbered  Operational  Fleet  commanders,  2nd  Fleet  on  the 
Atlantic  coast  and  6th  Fleet  in  the  Mediterranean  (likewise 
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in  the  Pacific  by  the  3rd  and  7th  Fleets) .  When  unit 
assignments  are  made  to  fulfill  these  requirements,  once 
again  unit  capabilities  are  considered,  e.g.,  unit  class, 
combat  systems  embarked  on  the  unit,  unit  speed  limits,  and 
fuel  limits,  in  the  case  of  submarines — depth  limits, 
under  ice  capabilities. 

9 .  Miscellaneous  Considerations 

This  category  would  include  such  things  as  Blue  and 
Gold  crew  training  periodicity  for  Ballistic  Missile 
Submarine  crews  and  all  other  out  of  the  ordinary 
considerations . 


D.  DYNAMIC  UNIT  RESCHEDULING 

As  noted  in  the  beginning  of  this  chapter,  the 
quarterly  employment  scheduling  process  performed  by 
CINCLANTFLT  is  primarily  a  manual  operation.  This  is 
likewise  the  case  when  it  comes  to  dynamically  rescheduling 
units  based  upon  changing  requirements.  Discussions  with 
CINCLANTFLT  personnel  highlight  an  extremely  labor 
intensive  effort  required  to  replace  ships  with  material 
casualties — in  fact  CINCLANTFLT  personnel  told  this  author 
they  were  so  busy  performing  this  manual  labor  that  they 
would  only  be  able  to  provide  limited  support  for  this 
research. 

The  primary  cause  of  dynamic  rescheduling  is  sudden 
degradation  of  a  unit,  e.g.,  material  casualties  precluding 
a  unit  from  fulfilling  its  requirements.  Due  to  a  change 
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in  a  disabled  unit's  M-rating  or  C-rating  it  is  identified 
as  requiring  replacement  by  a  comparable  unit  with  similar 
capabilities,  and  thus  dynamic  rescheduling  is  required. 

As  is  found  in  the  logic  of  FRESH,  this  activity  is  usually 
triggered  by  the  receipt  of  a  Casualty  Report  (CASREP)  or 
Unit  Status  and  Identity  Report  (UNITREP) .  Armed  with  the 
reported  casualty,  the  CINCLANTFLT  staff  then  commences  the 
long  drawn  out  manual  process  of  determining  a  replacement 
unit. 

When  a  unit  reports  a  casualty  and  a  subsequent 
inability  to  fulfill  a  requirement ,  the  CINCLANTFLT  staff 
checks  its  positional  database  (the  only  automated  aid  they 
have)  to  see  which  possible  replacement  units  are  in  the 
vicinity  of  the  unit  requiring  replacement.  Then  based  on 
their  personal  experience  with  what  capabilities  the 
possible  replacement  units  have,  and  after  manually 
checking  the  employment  schedules  of  possible  replacements, 
they  decide  on  a  replacement  unit.  There  is  no  database 
containing  unit  configuration  available  to  CINCLANTFLT — 
unit  capabilities  are  either  based  on  personal  experience 
with  a  specific  unit  or  through  manually  looking  up  a 
unit's  configuration.  This  manual  process  is  likewise 
undertaken  to  determine  which  units  have  what  special 
weapons  aboard,  e.g.,  harpoon. 

Utilizing  FRESH  technology  this  dynamic  rescheduling 
process  would  take  only  minutes,  however  operating  in  the 


manual  mode,  it  may  take  CINCLANTFLT  personnel  a  full  work 
day  or  longer,  involving  several  individuals;  the  benefit 
of  FRESH  is  obvious. 

E.  CINCLANTFLT  EQUIVALENT  OF  ALERT  SUMMARY 

As  depicted  in  Chapter  III,  paragraph  C.l,  FRESH 
automatically  provides  the  CINCPACFLT  staff  with  a  daily 
Alert  Summary  which  provide  a  listing  of  operational  units 
having  a  Combat  Readiness  Rating  of  C3  or  C4  (marginally 
combat  ready  or  not  combat  ready  respectively)  [NWP-10-1-11 
1985].  FRESH  generates  an  Alert  Summary  whenever  a  unit 
fails  to  meet  certain  thresholds  for  Mission/Combat 
Readiness.  CINCLANTFLT ' s  equivalent  of  the  FRESH  generated 
Alert  Summary  is  merely  a  manually  produced  summary  report 
of  all  CASREPs  and  UNITREPs  received  since  the  last  staff 
briefing.  One  major  problem  with  this  procedure  is  that 
they  don't  know  that  something  is  wrong  until  they  have  the 
CASREP  or  UNITREP  in  hand.  CASREPs  and  UNITREPs  can  be 
very  long  documents  which  are  not  in  a  very  user-friendly, 
readable  format;  put  simply,  crises  don't  jump  out  at  the 
reader  as  quickly  as  they  do  in  the  Alert  Summary  format 
provided  by  FRESH.  Each  CASREP  and  UNITREP  must  be  read  by 
the  CINCLANTFLT  staff,  digested,  and  summarized  into  a 
format  presentable  to  CINCLANTFLT  at  the  morning  briefings. 
This  manual  effort  takes  several  manhours  to  complete  and 
must  be  done  daily  to  provide  CINCLANTFLT  with  the  most  up 
to  date  information  on  the  readiness  of  the  Atlantic  Fleet. 
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F.  AD  HOC  QUESTIONS 


Due  to  CINCLANTFLT ' s  lack  of  automated  assistance,  they 
are  unable  to  perform  timely  ad  hoc,  "what  if?"  type  of 
questioning  regarding  the  scheduling  or  employment  of  units 
without  a  significant  amount  of  manual  effort  and  time.  In 
fact,  discussions  with  CINCLANTFLT  personnel  indicate  that 
the  process  of  doing  any  sort  of  sensitivity  analysis  on 
scheduling  is  so  time  consuming  that  they  rarely  even 
attempt  it.  This  puts  them  in  much  more  of  a  reaction  mode 
than  is  seen  in  CINCPACFLT. 

In  CINCPACFLT,  if  a  unit  reports  a  minor  casualty  that 
they  feel  could  develop  into  a  major  casualty,  sensitivity 
analysis  (what  if  this  unit  becomes  mission  incapable?)  can 
be  done  simply  through  FRESH.  However  CINCLANTFLT,  due  to 
the  tremendous  labor  required  to  perform  such  an  analysis, 
is  more  likely  to  wait  until  the  unit  is  mission  incapable 
before  doing  any  schedule  manipulation. 

G.  CINCLANTFLT  SCHEDULING  OUTPUTS 

The  intent  of  this  section  is  to  set  forth  what 
different  outputs  (or  changes  to  existing  outputs) 
CINCLANTFLT  would  desire  if  FRESH  is  transferred, 
l.  Employment  Schedules 

CINCLANTFLT  was  impressed  with  FRESH's  ability  to 
readily  update  employment  schedules  as  changes  in 
requirements  dictate,  however  they  desire  an  'automatic 
update'  capability  down  through  the  chain  of  command.  In 
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other  words,  they  would  like  FRESH  to  automatically 
generate  and  forward  the  new  approved/updated  employment 
schedule  down  through  the  chain  of  command  to  the  unit.  In 
this  way,  everyone  would  be  readily  assessed  of  the  changes 
and  could  make  required  adjustments. 

2 .  Port  to  Port  Routing 

As  noted  in  Chapter  III,  Section  E.6.a,  FRESH  will 
soon  have  the  capability  to  generate  land  avoidance  routes 
from  port  to  port.  CINCLANTFLT  is  pleased  with  this  idea 
however,  they  feel  that  the  FRESH  output  screen  format  may 
be  of  insufficient  granularity  (not  clear  or  precise 
enough)  to  provide  a  quality  picture  for  the  shorter  routes 
typically  taken  by  units  operating  in  the  Mediterranean. 
Likewise,  the  smaller  bodies  of  water  (e.g.,  Mediterranean 
Sea,  Black  Sea,  Ionian  Sea)  usually  traveled  by  deployed 
Atlantic  fleet  units  must  be  expanded  in  the  FRESH 
knowledge  base  to  show  greater  detail. 

Discussions  with  CINCPACFLT  personnel  indicate  that 
this  'granularity  upgrade'  is  presently  not  possible  due  to 
hardware  constraints  (not  enough  memory) ,  but  will  be 
available  if  a  proposed  hardware  upgrade  to  expand  the 
existing  memory  is  approved  and  implemented. 

3 .  NATO  Requirements 

CINCLANTFLT  is  a  double  hatted  position.  In 


addition  to  being  in  command  of  the  U.S.  Atlantic  Fleet, 
CINCLANTFLT  is  also  the  commander  of  the  Supreme  Allied 


Command  Atlantic.  Therefore  CINCLANTFLT  commands  both  U.S. 


and  NATO  forces  and  feels  that  in  addition  to  Atlantic  U.S. 
Naval  entities,  FRESH  should  also  include  NATO  forces. 

a.  Knowledge  Base  and  Database  Enhancements 
CINCLANTFLT  desires  to  add  NATO  naval  units, 

with  their  respective  characteristics  (weapons/sensors) ,  to 
the  FRESH  database.  In  addition  they  would  like  to  have 
Warsaw  Pact  units  included  in  the  knowledge  base  for 
tracking  purposes. 

b.  NATO  Mobilization 

In  the  event  if  a  crisis  situation  that  would 
trigger  a  NATO  response,  CINCLANTFLT  would  want  the 
capability  to  'switch'  on  NATO  forces  such  that  they  would 
be  equally  considered  with  U.S.  forces  as  replacement  units 
in  so  far  as  FRESH  is  concerned.  Ideally  they  would  prefer 
that  these  'switches'  be  country  based  in  addition  to  a 
NATO  collective  switch.  This  country  based  switching  would 
allow  CINCLANTFLT  to  only  consider  units  from  those  NATO 
countries  that  were  actually  called  into  action. 

H.  CAN  FRESH  HELP? 

Several  CINCLANTFLT  schedulers  indicate  that  they 
looked  forward  to  the  installation  of  FRESH.  Their 
scheduling  process,  as  it  exists  today,  is  so  labor 
intensive  that  any  assistance  would  be  instantly  accepted. 
In  terms  of  the  Nolan  Stage  Model  of  information  systems, 
it  is  felt  that  CINCLANTFLT  would  almost  instantly  jump 
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from  the  initiation  stage  (limited  use  by  small  number  of 


users)  to  the  contagion  stage  (proliferation  of  use,  many 


users)  [DAVIS  1985:451].  In  other  words,  it  is  felt  that 


FRESH  would  almost  instantaneously  be  identified  by 


CINCLANTFLT  as  an  invaluable  tool  in  terms  of  scheduling, 


alert  summary  generation  and  ad  hoc  query  ability. 


I .  CHAPTER  SUMMARY 


In  this  chapter,  the  CINCLANTFLT  perspective  toward 


scheduling  was  set  forth.  Discussion  centered  on  their 


Long  Range  Employment  Scheduling  system,  unit  replacement 


scheme  and  their  lack  of  an  effective  mechanism  with  which 


to  perform  ad  hoc/sensitivity  analysis  for  unit 


replacement.  The  labor  intensive  nature  of  the  CINCLANTFLT 


system  has  been  contrasted  with  the  automated  capabilities 


of  FRESH  where  appropriate. 


Through  discussion  with  CINCLANTFLT  personnel,  the 


strong  impression  is  that  offering  FRESH  to  them  would  be 


equal  to  offering  a  tractor  to  a  farmer  that  has  for  years 


been  plowing  with  a  horse.  Use  of  the  FRESH  prototype  in 


CINCPACFLT  sets  them  light  years  ahead  of  their  manually 


functioning  Atlantic  Fleet  counterparts. 


FRESH  input  and  output  requirements  for  CINCLANTFLT 


were  discussed.  It  was  noted  that  little  if  any  changes 


need  to  take  place  on  the  input  side  to  transfer  FRESH  to 


the  Atlantic.  Concerning  FRESH  outputs,  certain 


CINCLANTFLT  specific  requirements  have  been  addressed  and 
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no  doubt  once  CINCLANTFLT  becomes  more  familiar  with  FRESH 
their  desire  to  tailor  FRESH  more  specifically  to  their 
needs  will  require  further  changes  to  FRESH  outputs. 
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The  United  States  Navy,  with  its  construction  of  the 
prototype  expert  system  FRESH,  is  pushing  forward  the 
frontier  of  technology.  Although  problems  with  FRESH  do 
exist  and  have  been  highlighted  in  Chapter  III,  it  is 
nonetheless  an  exceptional  system  which  warrants  continued 
attention  and  funding. 

A.  CONCLUSIONS 

The  overall  goal  of  this  research  was  to  identify 
changes  in  FRESH  system  inputs  and  system  outputs  in  order 
to  meet  the  requirements  of  the  Atlantic  Fleet  and 
effectively  transport  FRESH  to  the  Commander  in  Chief 
Atlantic  Fleet.  It  is  felt  that  this  objective  was  attained 
and  that  this  research  will  be  a  useful  document  when  FRESH 
transference  to  the  Atlantic  Fleet  actually  takes  place. 

The  overall  conclusion  of  this  thesis  is  that,  in  terms  of 
system  inputs  and  outputs,  FRESH  can  (with  limited 
modification)  be  transferred  to  CINCLANTFLT.  Specific 
system  input  and  output  changes  are  outlined  below, 
l-  FRESH  Required  System  Input  Changes 

The  present  system  inputs  utilized  by  FRESH  were 


well  thought  out,  consequently  all  FRESH  inputs  are  all-Navy 
documents,  i.e.,  documents  that  are  identical  throughout  the 
Navy.  Therefore,  if  FRESH  were  to  be  transported  to 


CINCLANTFLT  there  appear  to  be  no  problems  or  additional 


costs  associated  with  changes  in  system  inputs.  The 

all-Navy  FRESH  system  inputs  are  shown  in  Figure  5-1 
(repeated  from  Chapter  III) . 


REAL-TIME  LOAD — PACACE  (Blue  Positional  Reports) ,  FOSIC 

(Red  Positional  Reports) . 

WWMCCS  LOAD — UNITREP  (subset).  Ship's  Positional  data 

(Departure  Report,  etc.). 

TAPE  LOAD — Weapons  Loadout,  Quarterly  Employment  Schedule. 

TAPE  LOAD  (Quarterly) — Configuration  data  from  NOSC. 

MANUAL  LOAD — CASREP  data,  MOVREP  data. 

FUTURE  INPUT — Port  Information,  Routing  Information 

FRESH  System  Inputs. 

Figure  5-1  FRESH  System  Inputs 

2.  FRESH  Required  System  Output  Changes 

Several  FRESH  system  output  changes  required  by 
CINCLANTFLT  have  been  identified.  However,  it  is  felt  that 
once  CINCLANTFLT  acquires  hands-on  experience  with  FRESH, 
additional  changes  will  be  forthcoming. 

CINCLANTFLT * s  desired  changes  to  the  present  FRESH 
output  are  summarized  below.  (Estimates  of  man-months  of 
effort  are  based  on  the  authors  knowledge  of  systems 
analysis  and  design  techniques.) 

-  Automatic  generation  and  forwarding  of  approved,  updated 
quarterly  employment  schedules  down  the  chain  of  command 
to  the  unit  involved.  (Currently  FRESH  does  not  possess 
this  capability.  Estimate  six  man-months  of  effort  to 
complete. ) 


Enhancement  of  the  Port  to  Port  routing  CRT  screen 
presentation  to  more  clearly  represent  the  European 
operating  areas.  (If  the  proposed  FRESH  memory 

expansion  is  approved  and  installed,  enhancement  of  the 
CRT  screens  will  be  possible.  Estimate  three  man-months 
of  effort  to  complete.) 


Reflect  NATO  units  and  their  respective  capabilities 
within  the  database  such  that  they  may  be  output  as 
possible  replacement  units  in  time  of  crisis,  i.e.,  when 
collective  NATO  action  is  required.  (Currently  FRESH 
depicts  only  U.S.  Navy  units  when  considering  possible 
replacement  units.  Estimate  nine  to  twelve  man-months 
of  effort  to  complete.) 


Provide  an  ability  to  switch  on/off  NATO  units  (by 
country)  in  the  event  that  not  all  NATO  countries 
equally  respond  to  a  given  crisis.  (Currently  FRESH 
does  not  possess  this  capability.  Estimate  six 
man-months  effort  after  NATO  units  are  loaded  into  the 
database. ) 


B.  RECOMMENDATIONS 

It  is  recommended  that  FRESH  be  transported  to 
CINCLANTFLT .  No  change  in  FRESH  system  inputs  appear  to  be 
required  and  the  few  output  changes  identified  in  this 
thesis  should  be  readily  accomplished.  But  it  is  important 
that  CINCLANTFLT ' s  proposed  output  changes  be  implemented 
prior  to  transportation  of  the  system.  By  having  the 
Atlantic  FRESH  'ready  to  go'  prior  to  its  installation  at 
CINCLANTFLT,  their  personnel  will  be  spared  the  turmoil  of 
learning  a  new  automated  system  and  simultaneously  going 
through  the  analysis  and  design  stages  for  their  output 
changes . 

It  is  felt  that  the  unique  CINCLANTFLT  output 
requirements  will  not  be  extremely  difficult  to  attain.  The 
author  estimates  a  development  period  of  at  least  nine 
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months  (requiring  at  least  27  man-months  of  effort)  to 
design  and  implement  the  new  output  requirements. 

This  research  has  presented  the  power  of  FRESH?  power 


that  will  be  invaluable  to  CINCLANTFLT. 


In  today's 


atmosphere  of  decreasing  operational  forces  coupled  with 
increasing  operational  commitments,  it  is  essential  that 
this  automated  tool,  FRESH,  be  used  to  upgrade  the  east 
coast  manual  mode  for  Fleet  scheduling. 


APPENDIX  A 


CINCPACFLT  GOALS  FOR  THE  FRESH  PROTOTYPE 

Description:  This  appendix  provides  a  complete  listing  of 
the  CINCPACFLT  goals  for  the  expert  system  prototype  FRESH 
as  set  forth  in  [DELEOT  1987 : CDDEC2/C] . 


CINCPACFIT  GOALS  FOR  THE  FRESH  PROTOTYPE 


1)  to  assist  in  planning/decision  making  process  employing 
experience  and  knowledge  of  user. 

2)  to  support  consistency  in  logical  planning/decision 
making  (reduce  role  of  emotion) . 

3)  to  collapse  response  time  for  significant  planning/ 
decision  making,  and  allow  CINCPACFLT  personnel  to  make 
faster  decisions. 

4)  to  identify  the  implications  of  combinations  of  events 
and  decisions. 

5)  to  support  development  of  early  offensive  postures. 

6)  to  provide  an  explicit  framework  for  inclusion  of 
counter  argument  ”What  if’s?" 

7)  to  identify  sensitivities  in  key  decisions — what  will 
be  the  effect  of  moving  ship  A  to  position  B? 

8)  to  facilitate  knowing  long  term  implications  of  a  course 
of  action  vs.  near  term  snapshot. 
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SAMPLE  FRESH  VIGNETTES  AND  CORRESPONDING  OUTPUTS 


Description:  These  vignettes  were  developed  by  the  Naval 

Oceanographic  System  Command  in  San  Diego,  California  to 
test  users  in  their  ability  to  utilize  FRESH's  Natural 
Language  Menu.  The  inclusion  of  this  material  in  this 
research  is  to  provide  the  reader  a  flavor  of  the  queries 
one  might  expect  to  ask  FRESH. 

The  numbered  statements  are  the  vignettes  that  were 
presented  to  the  "test"  users.  Subsequent  output  requested 
by  these  users  is  depicted  as  POSSIBLE  OUTPUT. 


’•  .%  vV.N  -VA  A  .V  S, 


in  mmm  u  uj  vm  ?. 
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SAMPLE  FRESH  VIGNETTES  AND  CORRESPONDING  OUTPUTS 


1.  Someone  has  asked  you  for  information  about  the  ships  in 
Task  Group  30.3  and  Task  Group  30.5. 

POSSIBLE  OUTPUT: 

List  of  ships  in  Task  Group  30.3  and  30.5. 

Location  of  ships  in  these  groups. 

Weapons  Loadout  for  the  individual  ships. 

2.  You  want  to  know  which  ships  in  Task  Group  30.5  have 
Harpoon  Capability. 

POSSIBLE  OUTPUT: 

List  of  all  ships  in  Task  Group  30.5  that  are  Harpoon 
Capable. 

3.  You  want  the  number  of  Harpoons  in  Task  Group  30.5. 
POSSIBLE  OUTPUT: 

List  of  ships  having  Harpoon  and  the  quantity  of 
missiles  on  each  ship. 

4 .  You  want  to  know  the  length  and  beam  of  the  SPRUANCE 
class  ships  in  Task  Group  30.0. 

POSSIBLE  OUTPUT: 

The  measurements  of  the  length  and  beam  of  the 
SPRUANCE  class  destroyers  in  Task  Group  30.0. 

5.  You  want  to  see  a  chart  showing  the  last  five  positions 
of  the  USS  Carl  Vinson. 

POSSIBLE  OUTPUT: 

A  graphical  display  of  the  USS  Carl  Vinson's  last  five 
reported  positions. 

6.  You  want  to  know  what  CASREPs  have  been  reported  by  USS 
Ranger  with  an  initial  report  date  of  after  18  July  87. 
POSSIBLE  OUTPUT: 

A  listing  of  all  USS  Ranger  CASREPs  that  have  an 
initial  date  of  18  July  87  or  later. 

7.  You  want  to  know  the  ASW  ratings  for  all  ships  in  Task 
Group  30.3. 

POSSIBLE  OUTPUT: 

A  listing  of  all  ships  in  Task  Group  30.3  with  their 
corresponding  ASW  ratings. 
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8 .  You  want  to  know  the  OPTEMPO  of  the  USS  Blue  Ridge 
through  the  second  quarter  of  FY87. 

POSSIBLE  OUTPUT: 

A  listing  of  all  USS  Blue  Ridge  operations  that  are 
scheduled  for  second  quarter  FY87. 

9.  You  want  to  locate  and  identify  a  USS  Los  Angeles  class 
submarine  in  order  to  support  an  emergent  operational 
requirement  at  30N  140W. 

POSSIBLE  OUTPUT: 

A  listing  of  all  USS  Los  Angeles  class  submarines  in 
the  area — their  respective  present  locations  and 
anticipated  times  to  transit  to  30N  140W. 

10.  You  want  to  see  a  true  view  projection  centered  at  30N 
14  0W . 

POSSIBLE  OUTPUT: 

A  true  view  projection  centered  at  30N  140W. 

11.  You  want  to  see  the  positions  of  all  USS  Los  Angeles 
class  submarines  on  the  chart  described  in  question 
(10)  . 

POSSIBLE  OUTPUT: 

A  true  view  projection  centered  at  3 ON  14 0W  with 
positional  markings  indicating  the  actual  locations  of 
all  USS  Los  Angeles  class  submarines  in  that 
particular  area. 

12.  You  want  to  know  the  amount  of  fuel  consumed  by  the  USS 
New  Jersey  in  transit  from  15N  165W  to  40N  150E. 

POSSIBLE  OUTPUT: 

An  estimated  amount  of  fuel  for  the  transit  based  on 
fuel  usage  statistics  for  the  USS  New  Jersey. 

13.  You  are  using  FRESH  to  monitor  alerts  occurring  to  the 
USS  Kitty  Hawk. 

POSSIBLE  OUTPUT: 

Alerts  as  they  occur  for  USS  Kitty  Hawk. 

14 .  You  want  to  see  the  alerts  that  occurred  to  the  USS 
Kitty  Hawk  during  the  last  week. 

POSSIBLE  OUTPUT: 

A  listing  of  alerts  for  the  USS  Kitty  Hawk  for  the 
desired  time  frame. 

15.  You  add  a  tickler  alert  to  FRESH  so  that  you  are 
notified  when  the  USS  Kitty  Hawk  arrives  in  the  Sea  of 
Japan. 

POSSIBLE  OUTPUT: 

A  hardcopy  alert  is  generated  when  the  USS  Kitty  Hawk 
is  enters  the  Sea  of  Japan — this  may  be  calculated/ 
projected  by  FRESH  or  may  result  from  an  actual 
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position  report  being  submitted  by  the  USS  Kitty  Hawk 
via  CASREP,  UNITREP,  etc. 

16.  You  want  to  see  the  route  that  the  USS  Jouett  will  take 
to  transit  from  its  current  position  to  15S  120E. 
POSSIBLE  OUTPUT: 

A  land  avoidance  route  (courses  to  take)  for  USS 
Jouett  to  take  in  order  for  her  to  get  from  her 
present  position  to  15S  120E. 

17.  You  want  to  see  the  quarterly  employment  schedule  for 
Task  Group  70. 

POSSIBLE  OUTPUT: 

A  list  of  all  ships  in  Task  Group  70  with  their 
corresponding  quarterly  employment  schedules. 

18.  FRESH  has  informed  you  of  an  alert  based  on  a  UNITREP 
for  the  USS  Jarrett.  You  want  FRESH  to  provide  you  with 
information  about  the  options  available  for  responding 
to  the  casualty. 

POSSIBLE  OUTPUT: 

An  ordered  list  of  possible  replacement  units  for  USS 
Jarrett.  An  explanation  of  why  replacement  ships  were 
ranked  the  way  they  were. 

19.  You  want  to  know  why  FRESH  identified  the  casualty  in 
vignette  (18)  as  being  significant. 

POSSIBLE  OUTPUT: 

FRESH  reasoning/logical  explanation  of  why  this 
casualty  was  considered  significant. 

20.  You  want  to  know  the  two  best  options  (possible 
replacement  units)  including  the  USS  Curtz  and  the  USS 
Tisdale  that  are  available  to  respond  to  the  casualty  in 
USS  Jarrett. 

POSSIBLE  OUTPUT: 

A  ranked  list  of  replacement  units  including  USS  Curtz 
and  USS  Tisdale. 

21.  You  want  to  know  the  impact  associated  with  the  first 
option  in  vignette  (20). 

POSSIBLE  OUTPUT: 

A  list  of  operations  that  the  first  option  (unit)  will 
miss  by  being  diverted  to  meet  the  requirements  of  the 
USS  Jarrett. 

A  cost  figure  in  terms  of  time  and  fuel  required  to 
transit  to  desired  location. 

22.  Why  did  FRESH  rank  option  1  as  better  than  option  2? 
POSSIBLE  OUTPUT: 

An  explanation  of  why  replacement  ships  were  ranked 
the  way  they  were. 
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APPENDIX  C 

FRESH  ANSWERABLE  SCENARIOS 

Description:  The  following  scenarios  were  provided  by  the 

Naval  Ocean  System's  Command  in  San  Diego,  California. 
Scenarios  are  presented,  along  with  possible  FRESH  queries 
that  would  enable  the  user  to  decide  what  course  of  action 
would  be  required  to  correct  the  problem  identified. 

Each  scenario  begins  with  a  date  time  grouped  message. 
In  scenario  q  the  departure  report  150700Z  MAR  87  indicates 
that  the  message  was  sent  on  the  15th  of  March  1987  at  0700 
Greenwich  mean  time. 
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FRESH  ANSWERABLE  SCENARIOS 


Scenario 


150700Z  MAR  87  DEPARTURE  REPORT 


CG-18  (USS  WORDEN)  will  depart  Pearl  Harbor  at  150830Z  MAR 
87  to  participate  in  a  Sea  of  Japan  transit  in  three  days. 
The  Sea  of  Japan  transit  requires  the  following 
capabilities: 

S PS-10  Surface  Search  Radar 
S PS-48  3D  Air  Search  Radar 
SQS-23  Sonar 

CG-18  (WORDEN)  Primary  Mission  Areas: 

AAW,  ASW,  ASU,  MOB,  CCC,  ELW 


UNITREP  001  as  of  161440Z  MAR  87 


CG-18  (WORDEN)  reports  that  it's  SPS-48  Air  Search  Radar  is 
inoperative: 

>  C— 3  CASREP  reported  on  SPS-48 

>  M— 3  reported  on  AAW  (anti  aircraft  warfare)  mission  area 
Possible  FRESH  Queries  to  Determine  Required  Action 

a)  What  is  the  WORDEN's  estimated  time  of  repair  for  the 
SPS-48? 

b)  What  other  cruisers  are  available  in  Pearl  Harbor  with 
an  SPS-48? 

c)  Display  the  location  of  all  cruisers. 

d)  What  is  the  employment  schedule  for  USS  HALSEY  and  USS 
FOX? 

e)  What  is  the  status  of  USS  HALSEY'S  SPS-48  radar? 

f)  What  is  the  percentage  of  fuel  remaining  for  USS  HALSEY? 


a 


B 


Scenario 


11 


221630Z  MAY  87  DEPARTURE  REPORT 


CG-29  (JOUETT)  and  DDG-996  (CHANDLER)  have  been  selected  to 
transit  the  Sea  of  Okhotsk  to  demonstrate  the  right  of  free 
passage  in  international  waters  contiguous  to  the  Soviet 
Union.  Because  of  the  sensitivity  of  the  mission,  the 
following  capabilities  are  required: 


CG-29  (JOUETT) 

SQS-26  Sonar 

SLQ-32  V ( 3 ) 

SM-2  (ER) 

SPS-48  3D  Radar 
S PS-10  Surface  Radar 


DDG-996  (CHANDLER) 

SQS-53  Sonar 
LAMPS  Helos 
SLQ-32  V (2 ) 

SM-2  (MR) 

TACTAS  (Towed  Array  Sonar) 
SPS-48  3D  Radar 
S PS-10  Surface  Radar 


222100Z  MAY  87  CASREP 


DDG-996  (CHANDLER)  has  developed  a  propulsion  problem  which 
is  estimated  to  take  two  weeks  to  repair: 

>  M-3  reported  on  MOB  (mobility) 

Possible  FRESH  Queries  to  Determine  Required  Action 

a)  What  is  the  position  of  DDG-996  (CHANDLER)? 

b)  What  is  the  position  of  CG-29  (JOUETT) ? 

c)  What  other  ships  are  within  500  miles  of  DDG-996 
(CHANDLER) ? 

d)  What  is  the  position  of  USS  CALLAGHAN  (a  ship  of  the 
same  class)? 

e)  What  are  the  primary  mission  area  M-ratings  for  USS 
CALLAGHAN? 

f)  Display  USS  CALLAGHAN'S  CASREP  status. 

g)  Display  USS  CALLAGHAN'S  capabilities. 

h)  Display  USS  CALLAGHAN'S  employment  schedule. 
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Scenario  #3 


051440Z  JUL  87  DEPARTURE  REPORT 


FFG-41  MCCLUSKY  has  been  assigned  tattletale  surveillance  of 
the  MINSK  Task  Group  during  its  operations  in  the  South 
China  Sea.  The  task  group  is  expected  to  depart  the  area 
120800Z  JUL  87.  The  primary  objective  of  the  surveillance 
is  intelligence  collection  on  the  MINSK  use  of  electronic 
sensors  and  communications  during  task  group  operations. 
Required  capabilities  are:  SPS-55  surface  search  radar  and 
LAMPS  MK  III  helicopter. 


UNITREP  003  as  of  061020Z  JUL  87 


FFG-41  MCCLUSKY  reports  surface  search  radar  unreliable. 

>CREQP:  C-3 

>M-3  reported  on  ELW 


Possible  FRESH  Queries  to  Determine  Required  Action 


a)  What  is  the  estimated  time  of  repair  for  MCCLUSKY' s 
SPS-55  surface  search  radar? 


b)  Display  locations  of  all  FFG-07  and  DD-963  class  ships 
in  the  South  China  Sea  area. 


c)  Does  DD— 976  have  a  LAMPS  III  helicopter? 

d)  What  is  the  CASREP  status  of  DD-976? 

e)  How  far  is  DD-976  from  the  MINSK  task  group? 

f)  What  is  DD-976' s  percentage  of  fuel  remaining? 

g)  What  is  DD-976 's  overall  combat  readiness  rating? 

h)  What  is  DD-976 's  overall  primary  mission  area  rating? 

i)  What  is  DD-976 's  present  employment  schedule? 

j)  What  is  DD-976 's  present  0PTEMP0? 


k)  When  is  DD-976  supposed  to  complete  their  WESTPAC 
deployment? 
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Scenario  #4 


121000Z  AUG  87  MOVEMENT  REPORT 


Due  to  a  civil  disturbance,  CG-24  REEVES  and  DD-976  MERRILL 
have  been  selected  to  participate  in  a  show  of  force  off  the 
coast  of  Port  Moresby,  New  Guinea  in  four  days.  Because  of 
a  highly  volatile  situation,  the  following  capabilities  are 
critical  should  the  evacuation  of  American  civilians  require 
shore  bombardment: 

Phalanx  CIWS  Mk  16 
5-inch  54-cal  DP  MK-45  Gun 
3-inch  50-cal  AA  MK-33  Gun 

CG-24,  DD-976  Primary  Mission  Areas: 

AAW,  ASW,  ASU,  MOB,  CCC,  ELW 


UNITREP  001  as  of  141440Z  AUG  87 


>  DD-976  reports  C-3  CASREP  on  Phalanx  gun  control  system 

>  Primary  Mission  areas  affected:  ASU,  AAW,  AMW 

Possible  FRESH  Queries  to  Determine  Required  Action 

a)  What  is  the  estimated  time  of  repair  for  the  MERRILL'S 
C3  CASREP  on  Phalanx  close  in  weapon  system? 

b)  What  is  REEVES'  overall  M-rating? 

c)  What  is  REEVES'  current  CASREP  status? 

d)  What  other  DD-963  class  ships  are  within  1500  miles  of 
Port  Moresby,  New  Guinea? 

e)  What  is  O'BRIEN'S  current  employment? 

f)  What  is  O'BRIEN'S  current  speed?  maximum  speed? 

g)  What  is  O'BRIEN'S  CASREP  status? 

h)  What  weapons  does  O'BRIEN  have  aboard? 

i)  What  is  O'BRIEN'S  percentage  of  fuel  remaining? 


281205Z  NOV  86  DEPARTURE  REPORT 


CV-64  CONSTELLATION  with  FF-1086  BREWTON  will  participate  in 
a  space  craft  recovery  mission.  The  space  craft  will  splash 
down  at  32N  144W  at  041500Z  DEC  87  in  the  central  Pacific. 
The  following  capabilities  will  be  required: 

LAMPS  helicopter 

SPS-10  Surface  Search  Radar 

SPS-40  Air  Search  Radar 


291100Z  NOV  87  CASREP  REPORT 

FF-1086  BREWTON  reports  LAMPS  helicopter  mainrotor  damaged 
>C— 3  reported  on  EQP 

Possible  FRESH  Queries  to  Determine  Required  Action 

a)  What  is  the  estimated  time  of  repair  on  the  LAMPS? 

b)  What  is  the  position  of  the  CONSTELLATION? 

c)  What  is  the  position  of  the  BREWTON? 

d)  What  ships  are  within  1500  miles  of  BREWTON? 

e)  What  are  the  capabilities  of  CALLAGHAN? 

f)  What  are  the  primary  mission  area  ratings  of  the 

CALLAGHAN? 

g)  What  are  the  resource  area  C-ratings  on  CALLAGHAN? 

h)  What  are  CASREP  dates  and  descriptions  and  estimated 

times  of  repair  for  CALLAGHAN? 

i)  What  is  the  position  of  CALLAGHAN? 

j)  What  is  the  distance  from  CALLAGHAN  to  BREWTON? 

k)  What  other  ships  are  within  2000  miles  of  32N  144W? 

l)  What  is  the  CALLAGHAN'S  employment  schedule? 
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Scenario  #6 


021115Z  JAN  87  MOVEMENT  REPORT 


DDG-9  TOWERS  is  conducting  three  a  week  good  will  visit  to 
Malaysia.  Malaysia  has  been  attempting  to  close  its  ports 
to  DD  and  CG  surface  combatants.  Therefore,  the  port  visit 
has  high  political  ramifications.  Following  the  visit, 
DDG-9  TOWERS  will  have  a  ten  (10)  day  R  &  R  port  call  in 
Hong  Kong. 


UNITREP  004  as  of  121440Z  JAN  87 


DDG-9  TOWERS  struck  an  underwater  object  at  245S  102E  in  the 
Indian  Ocean  enroute  to  Singapore  damaging  number  1  main 
shaft  and  propeller. 

>loss  of  full  power  capability  on  number  1  main  engine. 

Speed  restricted  to  10  knots. 

>  M-3  reported  for  MOB. 


a)  How  far  is  TOWERS  from  Singapore? 

b)  What  other  DD  and  CG  surface  combatants  are  within  2000 
miles  of  Malaysia? 

c)  What  is  the  employment  of  THATCH? 

d)  How  far  is  TOWERS  from  Subic  Bay,  Philippines? 

e)  What  is  the  estimated  time  of  repair  for  number  1  main 

shaft  and  propeller? 

f)  How  far  is  TOWERS  from  Hong  Kong? 

g)  What  is  the  CASREP  status  of  THATCH? 

h)  What  is  the  percentage  of  fuel  remaining  for  THATCH? 

i)  What  is  THATCH's  maximum  speed  available? 

j)  What  is  THATCH's  present  employment? 

k)  What  is  STERRET's  present  employment  schedule? 
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